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

[Steve Hanson]

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 at uk.ibm.com
tel:+44-1962-815848



From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     Steve Hanson/UK/IBM at IBMGB
Cc:     "dfdl-wg at ogf.org" <dfdl-wg at 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 at 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 at uk.ibm.com
tel:+44-1962-815848 



From:        Mike Beckerle <mbeckerle.dfdl at gmail.com> 
To:        "dfdl-wg at ogf.org" <dfdl-wg at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20150217/79c5aa42/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parseUnparseMode.dfdl.xsd
Type: application/octet-stream
Size: 4168 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20150217/79c5aa42/attachment-0001.obj>