So setVariable and newInstanceVariable are another example of the dfdl:length scenario that we recently discussed. We said that any non-outputValueCalc expression must be resolvable at the time it is unparsed otherwise the unparser must detect the deadlock and throw an error.

Sorry but I don't follow your schema. When unparsing there is no backtracking of choice branches (unless trying to apply defaults to an entirely missing choice element) so if the parse created something for the first choice branch, the first choice branch will be output when unparsing.

Regards

Steve Hanson
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848

From: Mike Beckerle <mbeckerle.dfdl@gmail.com>
To: Steve Hanson/UK/IBM@IBMGB
Cc: "dfdl-wg@ogf.org" <dfdl-wg@ogf.org>
Date: 17/02/2015 18:05
Subject: Re: [DFDL-WG] bug: calendarLanguage property can be expression, but does not say no forward references allowed.

So, to follow up, even with this backward-only reference restriction, if a setVariable or newVariableInstance (the default value expression) refers (properly, in the backward direction) to an element, well if we are unparsing, then that element can have an outputValueCalc. So is the variable expression an error if that outputValueCalc cannot yet be evaluated, or is that expression effectively delayed until the outputValueCalc can have a value.

E.g., if one is implementing DFDL unparsing, and delivering the infoset element by element to the unparse processor, then an outputValueCalc expression can end up being delayed until the infoset elements it requires have arrived. When a setVariable or newVariableInstance expression refers to such an outputValueCalc element, does it inherit this delayed characteristic, or is this an error?

The example for this would be when one must compute the length of something, but then use that length in more than one place. Concretely, two variable-length elements have their length stored in elements that precede them, and then a third element stores the sum of both of those lengths. In this situation one would want to put the length computation into a variable, and then reference that variable more than once from outputValueCalc expressions.

Originally, I thought the fact that setVariable and newVariableInstance are evaluated both parsing and unparsing made it clear that they have to refer backward only to parts of the infoset that are fully defined because that's the only thing that can make sense when parsing. But then I was able to construct a schema (attached) that enables sub-parts of the schema to be purely parser only or unparser only, as in:

    <xs:element name="root">
      <xs:complexType>
        <xs:sequence>
          <xs:sequence dfdl:hiddenGroupRef="mode:hDefModeGroup" />
          <xs:choice>
          <xs:sequence>
            <xs:group ref="mode:assertParsing"/>
            
            <xs:element name="a" type="xs:int" dfdl:length="2" dfdl:lengthKind="explicit"/>
            <xs:element name="b" type="xs:string" dfdl:inputValueCalc="{ 'parsing' }" />
          </xs:sequence>
          <xs:sequence>
            <xs:group ref="mode:assertUnparsing"/>
            
            <xs:element name="a" type="xs:int" dfdl:length="2" dfdl:lengthKind="explicit"/>
            <xs:element name="b" type="xs:string" dfdl:length="0" dfdl:lengthKind="explicit"/>
          </xs:sequence>
          </xs:choice>
        </xs:sequence>
      </xs:complexType>
    </xs:element>

btw: the above does not violate UPA rules because of things in the group refs (which must be group refs, not hidden group refs) that are not hidden and distinguish the two arms of the choice.

On Feb 16, 2015 5:14 AM, "Steve Hanson" <smh@uk.ibm.com> wrote:
Section 23.1 makes the definitive statement about when forward references are allowed, but it is true that expression properties also make the statement so yes the phrase should be added to the description of calendarLanguage. It is also missing from choiceDispatchKey, and from setVariable.

Regards

Steve Hanson
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848

From: Mike Beckerle <mbeckerle.dfdl@gmail.com>
To: "dfdl-wg@ogf.org" <dfdl-wg@ogf.org>
Date: 13/02/2015 21:14
Subject: Re: [DFDL-WG] bug: calendarLanguage property can be expression, but does not say no forward references allowed.
Sent by: dfdl-wg-bounces@ogf.org

Well, of course dfdl:outputValueCalc can also have forward reference. I meant all properties except this.

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

On Fri, Feb 13, 2015 at 3:55 PM, Mike Beckerle <mbeckerle.dfdl@gmail.com> wrote:
Every property that can be an expression needs to stipulate "The expression must not contain forward references to elements which have not yet been processed."

There are only two exceptions which are for the message of asserts/discriminators.

This phrase is missing for calendarLanguage.

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
-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU