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

[Mike Beckerle]

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*
> <http://www.ibm.com/developerworks/library/se-dfdl/index.html>
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> IBM SWG, Hursley, UK
> *smh at uk.ibm.com* <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* <http://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>
>
>
> On Fri, Feb 13, 2015 at 3:55 PM, Mike Beckerle <*mbeckerle.dfdl at gmail.com*
> <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* <http://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>
>
> --
>  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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20150217/21107c5b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parseUnparseMode.dfdl.xsd
Type: application/xml
Size: 4168 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20150217/21107c5b/attachment.xsd>