[DFDL-WG] public comment "Non-deterministic outcome of setVariable evaluations"

[Mike Beckerle]

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20130930/a733643e/attachment.html>