Some email discussion before posting to the public comment forum may be helpful for this issue. Right now the rules say that all dfdl:newVariableInstance annotations for a schema component are always executed before any setVariable annotations. This is ok. One can introduce an extra sequence in order to allow a setVariable to occur before a newVariableInstance. (Personally: I would like to get a warning from my DFDL implementation if I write statement annotations at one annotation point that are not in the canonical order described in Errata 3.25) The problem is that the order of execution of multiple setVariable statements at one annotation point, or similarly, of multiple newVariableInstance at one annotation point, is not specified. This is what will get users into trouble. If there are multiple newVariableInstance annotations, then the order is important to understanding when exactly a new instance comes into scope, and whether the prior-scope's value for that variable can be read as part of the default value expressions. Consider this: <dfdl:newVariableInstance ref="save">{ $delim }</dfdl:newVariableInstance> <dfdl:newVariableInstance ref="delim">{ ../hdr/d }</dfdl:newVariableInstance> We need to specify whether $delim in the first annotation is referring to that variable before the new instance is created, or after. I suggest that before is more intuitive, as that is lexical order. Note however, that this means: <dfdl:newVariableInstance ref="prefix">{ fn:concat($prefix, "_", fn:name()) }</dfdl:newVariableInstance> is allowed and is not recursion. The expression is referring to $prefix from the enclosing scope, and then initializing a new instance of $prefix for the scope contained by this schema component. The same logic applies to dfdl:setVariable annotations. The order needs to be controlled by the user. I suggest the fix for this issue is as follows: Errata 3.20, 3.21, and Errata 3.25 must be modified (and the corresponding sections of the spec) For errata 3.20, and errata 3.21 the sentence: "However, the order of execution among them is not specified. Schema authors can insert sequences to control the timing of evaluation of statements more precisely." is replaced by: "The order of execution is specified in errata 3.25." Errata 3.25 is modified. Numbered item 3 of both the first list and second list is replaced by: 3. dfdl:setVariable(s) - in lexical order Numbered item 2 of the second list is replaced by: 2. dfdl:newVariableInstance(s) - in lexical order These two paragraphs are added below the numbered lists to clarify what 'lexical order' means. The dfdl:setVariable annotations at any one annotation point of the schema are always executed in lexical order. However, dfdl:setVariable annotations can also be found in different annotation points that are combined into the resolved set of annotations for one schema component. In this case, the order of execution of the dfdl:setVariable statements from any one annotation point remains lexical, but it is unspecified what the order of execution is across dfdl:setVariable statements coming from different annotation points. The dfdl:newVariableInstance annotations at any one annotation point of the schema are always executed in lexical order. However, dfdl:newVariableInstance annotations can also be found in different annotation points that are combined into the resolved set of annotations for one schema component. In this case, the order of execution of the dfdl:newVariableInstance statements from any one annotation point remains lexical, but it is unspecified what the order of execution is across dfdl:newVariableInstance statements coming from different annotation points. ---------------------- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy<http://www.ogf.org/About/abt_policies.php>