Re: [DFDL-WG] bug: calendarLanguage property can be expression, but does not say no forward references allowed.

17 Feb 2015

      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"/>
            <!-- This is parser only -->
            <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"/>
            <!-- This is unparser only -->
            <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