Understanding Enumeration Order

If the definition of the name of a relationship or the name or type of an entity contains substitution variables that have several possible values, the parser enumerates the possible combinations. The loops are performed at the boundary of the innermost <entity> or <rel> tag that contains the reference. (Loops for the target or source are raised to the <rel> level.)

Once the value for a variable has been established at a loop insertion point, it is propagated unchanged to the tags within the loop tag. So an entity attribute specification that refers to a variable used in the name of the entity will always use the exact single value that was used in the name.

If the expression for a name or type fails, the specified entity or relationship is locked out from processing for the particular combination of values that caused it to fail. This behavior can be used to completely block whole branches of entity/relationship definition tags:

<entity ...>
  <type switch-var='%a'>
    <case eq='1' value='TABLE'/>
  </type>
  <rel name='InsertsTable' ..../>
</entity>
<entity ...>
  <type switch-var='%a'>
    <case eq='2' value='MAP'/>
  </type>
  <rel name='Sends'..../>
</entity>

If %a is 1, the first declaration tree is used, and the table relationship is generated; the second declaration is blocked. If %a is 2, the second declaration tree is used, and the map relationship is generated; the first declaration is blocked.

Note: These enumeration rules require that the value of a repository entity attribute not depend on variables used in the name of an enclosing <rel> tag, unless that variable is also used in the name of the entity itself. Otherwise, the behavior is undefined.