[DFDL-WG] questions on setVariable

Tue Sep 10 14:13:35 EDT 2013

If the first setVariable executes first, that will read variable baz, which
will cause the second setVariable to SDE because you cannot set after the
variable has been read. I believe this is the right semantics for this
schema, because both these setVariable annotations are written at the same
annotation point.

If the second setVariable executes first, that will assign variable baz,
which is OK, then when the first setVariable executes, it will get the
value that was just assigned.

While the spec says you shouldn't depend on this kind of ordering stuff, I
think it is pretty unsatisfactory if the order is unspecified. Section 9.5
lays out the order of the different kinds of statement annotations relative
to each other, but doesn't say what happens between two setVariable
statements that appear at the same annotation point. I think the execution
order needs to be specific within the annotations at one annotation point.

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>

On Tue, Sep 10, 2013 at 1:50 PM, Steve Hanson <smh at uk.ibm.com> wrote:

> 1) I'll let Tim comment more on this but a relative expression uses as its
> context the current element on the stack. So using '.' on a simple element
> or its type resolves to the simple element, and using '.' on a complex
> element or a group child (recursively) of a complex element resolves to the
> complex element. Same deal when using the '..' parent axis, so beware - as
> this example shows:
>
> <xs:element name="root">
>         <xs:complexType>
>                 <xs:sequence>
>                         <xs:element name="delim" type="xs:string"/>
>                         <xs:element name="body">
>                                 <xs:complexType>
>                                         <xs:sequence
> dfdl:separator="{../delim}">
>
> ...and not {../../delim} !  This is all implied by the way XPath works.
> XPath only knows about elements.
>
> 2) I don't see why Jonathan's example could give an SDE.  The
> defineVariables will always be executed first. However the result is
> ambiguous, depending on the order each setVariable is executed, as 'bar'
> could end up as 'biff' or 'fooey'. "Schema authors can insert sequences to
> provide more precise control over when variables are set" - quote from
> section 9.5.3 (errata 3.25).
>
> 3) To Mike's comment, the order of execution of setVariable and
> newVariableInstance on the same annotation is strictly defined, see section
> 9.5 (errata 3.25)
>
> Regards
>
> Steve Hanson
> Architect, IBM Data Format Description Language (DFDL)
> 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:        "Cranford, Jonathan W." <jcranford at mitre.org>,
> Cc:        "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>
> Date:        10/09/2013 18:23
> Subject:        Re: [DFDL-WG] questions on setVariable
> Sent by:        dfdl-wg-bounces at ogf.org
> ------------------------------
>
>
>
> Those are both public-comment-class issues.
>
> The issue of what does "." mean in various places is interesting. It is
> referring to an infoset node, but how to explain exactly which one it is....
>
> The out-of-order issue with evaluation that you mention is definitely an
> issue. The schema you gave will work or SDE depending on the order of
> evaluation of the statements and the language is not precise enough to say
> what the order is. I think the order of the setVariable and
> newVariableInstance statements at any annotation point, must be linear
> first to last. The order of setVariable and newVariableInstance combined
> into the resolved set of annotations, but from multiple annotation points
> (e.g., an element and a global type definition it references), those can be
> interleaved in any order.
>
>
> 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 Tue, Sep 10, 2013 at 12:53 PM, Cranford, Jonathan W. <*
> jcranford at mitre.org* <jcranford at mitre.org>> wrote:
> These questions may go towards public comment if the answers aren't
> straight-forward.  Section references are against latest editor's draft.
>
>
>
> ·        Section 7.9 - 5th paragraph after first example - "A
> dfdl:setVariable value expression may refer to the value of this element
> using a relative path value '.'. "
>
>
>
> Which element?
>
>
>
> If dfdl:setVariable is attached to a simpleType, then the "element"
> referred to here is the element of that type, correct?
>
>
>
> But when it's attached to group reference, sequence, or choice, is it the
> parent element which contains the group reference, sequence, or choice?
>
>
>
>
>
> ·        Section 7.9 - next-to-last paragraph:  "However, the order of
> execution among them is not specified."
>
>
>
> Wouldn't this be ambiguous, then?
>
>
>
> <xs:schema>
>
>     <xs:annotation>
>
>     <xs:appinfo source="*http://www.ogf.org/dfdl/*<http://www.ogf.org/dfdl/>
> ">
>
>       <xs:defineVariable name="bar" />
>
>       <xs:defineVariable name="baz" defaultValue="biff"/>
>
>     </xs:appinfo>
>
>     </xs:annotation>
>
> ...
>
>     <xs:element name="foo">
>
>       <xs:annotation>
>
>         <xs:appinfo source="*http://www.ogf.org/dfdl/*<http://www.ogf.org/dfdl/>
> ">
>
>           <xs:setVariable ref="bar" value="{$tns:baz}"/>
>
>           <xs:setVariable ref="baz" value="fooey"/>
>
>         </xs:appinfo>
>
>       </xs:annotation>
>
>     </xs:element>
>
> ...
>
> </xs:schema>
>
>
>
> If the order of execution isn't specified, isn't it ambiguous whether
> tns:bar gets the value of "biff" (defaultValue of tns:baz) or "fooey"?
>
>
>
>
>
> Respectfully,
>
>
>
> --
>
> Jonathan W. Cranford
>
> Senior Information Systems Engineer
>
> The MITRE Corporation (*http://www.mitre.org* <http://www.mitre.org/>)
>
>
>
> --
>   dfdl-wg mailing list
>   *dfdl-wg at ogf.org* <dfdl-wg at ogf.org>
>   *https://www.ogf.org/mailman/listinfo/dfdl-wg*<https://www.ogf.org/mailman/listinfo/dfdl-wg>
> --
>  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/20130910/06a78147/attachment.html>