- dfdl-wg - lists.ogf.org

Re: [DFDL-WG] public comment "Non-deterministic outcome of setVariable evaluations" (Action 229)
by Mike Beckerle 07 Oct '13

07 Oct '13

Revised proposal that fully specifies evaluation order for setVariable and newVariableInstance. --------------------------------------------- Errata 3.20, 3.21, and Errata 3.25 must be modified (and the corresponding sections of the spec) For errata 3.20, and errata 3.21 the sentence: "However, the order of execution among them is not specified. Schema authors can insert sequences to control the timing of evaluation of statements more precisely." is replaced by: "The order of execution is specified in errata 3.25." Errata 3.25 is modified. Numbered item 3 of both the first list and second list is replaced by: 3. dfdl:setVariable(s) - in lexical order, innermost schema component first Numbered item 2 of the second list is replaced by: 2. dfdl:newVariableInstance(s) - in lexical order, innermost schema component first These two paragraphs are added below the numbered lists to clarify what 'lexical order, innermost schema component first' means. The dfdl:setVariable annotations at any one annotation point of the schema are always executed in lexical order. However, dfdl:setVariable annotations can also be found in different annotation points that are combined into the resolved set of annotations for one schema component. In this case, the order of execution of the dfdl:setVariable statements from any one annotation point remains lexical. The order of execution of the dfdl:setVariable annotations different annotation points follows the principle of innermost first, meaning that a schema component that references another schema component has its dfdl:setVariable statements executed after those of the referenced schema component. For example, if an element reference and an element declaration both have dfdl:setVariable statements, then those on the element declaration will execute before those on the element reference. Similarly dfdl:setVariable statements on a base simple type execute before those of a simple type derived from it. The dfdl:setVariable statements on a simple type execute before those on an element having that simple type (whether by reference, or when the simple type is lexically nested within the element declaration). The dfdl:setVariable statements on the sequence or choice within a global group definition execute before those on a group reference. The dfdl:newVariableInstance annotations at any one annotation point of the schema are always executed in lexical order. However, dfdl:newVariableInstance annotations can also be found in different annotation points that are combined into the resolved set of annotations for one schema component. In this case, the order of execution of the dfdl:newVariableInstance statements from any one annotation point remains lexical. The order of execution of the dfdl:newVariableInstance annotations different annotation points follows the principle of innermost first, meaning that a schema component that contains or references another schema component has its dfdl:newVariableInstance statements executed after those of the contained or referenced schema component. For example, if a group reference and the sequence or choice group of a group definition both have dfdl:newVariableInstance statements, then those on the global group definition will execute before those on the group reference. 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>

1 0

Public comment 116 - Japanese CCSID 943
by Steve Hanson 07 Oct '13

07 Oct '13

Please see below discussion of the issue raised by public comment 116. While there is a simple workaround, the real issue is that ccsid 943 is in daily use in Japan for zoned decimals and DFDL does not support that. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 07/10/2013 14:05 ----- ICU library treats the ccsid '943' as ICU ibm-943_P130-1999 which is not 100% ASCII compatible due to two code points being different - 0x5C and 0x7E. There is another encoding ICU ibm-943_P15A-2003 which is ASCII compatible, commonly called Shift_JIS. The difference is one that you are probably familiar with - the backslash is replaced by the Yen symbol. Here is the extract from ICU converter site: Internal Converter Name IBM IANA ibm-943_P15A-2003 Shift_JIS MS_Kanji csShiftJIS windows-31j csWindows31J ibm-943_P130-1999 ibm-943 This causes DFDL to reject the ccsid '943' when used on a zoned decimal on the grounds that it is not ASCII-compatible. Why does DFDL do this? It's because it is being safe. So far, we have identified 4 different 'overpunching' schemes for ASCII zoned decimals, and there might well be one or two more used by less common machine architectures: asciiStandard: ASCII characters '0123456789' (0x30-0x39) and 'pqrstuvwxy' (0x70-0x79) for negative sign punch. asciiTranslatedEBCDIC: ASCII characters '{ABCDEFGHI' (0x7B, 0x41-0x49) and '}JKLMNOPQR' (0x7D, 0x4A-0x52) for negative sign punch. asciiCARealiaModified: ASCII characters '0123456789' (0x30-0x39) and '<SP>!"#$%&'()' (0x20-0x29) for negative sign punch. asciiTandemModified: ASCII characters '0123456789' (0x30-0x39) and control characters 0x80-0x89 for negative sign punch. In case other schemes are discovered that use different byte range for negative sign punch (eg, 0x50 to 0x59), the DFDL specification has said that ASCII zoned decimals must be in a 100% ASCII compatible encoding. What we can observe is that ibm-943_P130-1999 is actually safe for representing ASCII zoned decimals in all the above schemes, because the 0x5C and 0x7E characters do not match any of the ranges of bytes used by the schemes. And we can also observe that (apart from the special case of asciiTranslatedEBCDIC) the overpunching schemes simply use the bits in the first nibble of the byte, so any new scheme we discover is very unlikely to affect 0x5C or 0x7E. So, the DFDL specification *could* be changed to treat ibm-943_P130-1999 as ASCII compatible for zoned decimals. The alternative is to use a work around whereby in a DFDL schema that models a data stream in ccsid 943, the default is 943 but zoned decimals override this and use Shift_JIS. When this workaround was discussed with a Japanese user of IBM DFDL, the reaction was "Why do I have to go to that trouble? It should just work in 943." 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

2 1

Call For Abstract: NIST Data Science Symposium
by Steve Lawrence 04 Oct '13

04 Oct '13

I'm just letting the working group know that we are submitting an abstract today to give a presentation on DFDL at the NIST Data Science Symposium. Below is what we plan to submit. - Steve ---------------------------------------------- Title: Stop Writing Custom Data Parsers -- Write DFDL Instead! This talk gives an introduction to the Data Format Description Language (DFDL), how it can be used to parse both textual and binary data in a standardized way, and how this leads to less time spent on custom data parser development and consequently, more time spent on data processing and analysis. The talk will then describe the current DFDL implementations, with focus on the open-source Daffodil project and its design. It will conclude with a brief walkthrough of real DFDL examples, including commercial and scientific formats, and a demonstration of the parsing capabilities of Daffodil. The DFDL specification, which has completed a second round of public comments as part of the Open Grid Forum (OGF), is a modeling language for describing general text and binary data using a subset of XML Schema augmented with data format annotations. DFDL allows data to be read from its native format and presented as an instance of an information set or an XML document. DFDL also allows the reverse, through conversion of an information set back to its native format. By using the information set, this cleanly integrates with common XML utilities (e.g. XProc, XSLT, XQuery) for data processing and analysis regardless of the format of the native data. Two implementations of DFDL exist, as is required by the OGF to become a standard. The first, created by IBM as part of IBM WebSphere V8, is written in both Java and C and includes graphical tools for modeling, running, and debugging DFDL schemas. The second implementation, Daffodil, is an open-source project written in Scala, with a design focused on speed and correctness. With the two implementations making great strides, and the DFDL specification nearing standardization, DFDL is becoming a promising tool that will ease data parsing, processing, and analysis. Biography: Stephen Lawrence has worked as a software engineer at Tresys Technology since 2007, while contributing to the open-source Daffodil project as a core maintainer for almost two years. He works alongside Michael Beckerle, the co-chair of the DFDL Working Group, to develop Daffodil and improve the DFDL specification. Outside of Daffodil, he focuses on computer security applications, including file inspection and sanitization, Security Enhanced Linux (SELinux), and cross domain solutions.

2 2

OGF DFDL WG Call Minutes 2013-10-01
by Steve Hanson 02 Oct '13

02 Oct '13

Please find minutes from the above call at http://redmine.ogf.org/dmsf_files/13131?download= Public Comment The following set are now in Public Comment until 15th October. Revised DFDL 1.0 Specification: https://redmine.ogf.org/issues/117 DFDL Experience Document 1 (Spec Errata): https://redmine.ogf.org/issues/118 DFDL Experience Document 2 (Action 140): https://redmine.ogf.org/issues/119 Please download, review and create comments as necessary. Regards Steve Hanson Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

public comment "Non-deterministic outcome of setVariable evaluations"
by Mike Beckerle 01 Oct '13

01 Oct '13

Some email discussion before posting to the public comment forum may be helpful for this issue. Right now the rules say that all dfdl:newVariableInstance annotations for a schema component are always executed before any setVariable annotations. This is ok. One can introduce an extra sequence in order to allow a setVariable to occur before a newVariableInstance. (Personally: I would like to get a warning from my DFDL implementation if I write statement annotations at one annotation point that are not in the canonical order described in Errata 3.25) The problem is that the order of execution of multiple setVariable statements at one annotation point, or similarly, of multiple newVariableInstance at one annotation point, is not specified. This is what will get users into trouble. If there are multiple newVariableInstance annotations, then the order is important to understanding when exactly a new instance comes into scope, and whether the prior-scope's value for that variable can be read as part of the default value expressions. Consider this: <dfdl:newVariableInstance ref="save">{ $delim }</dfdl:newVariableInstance> <dfdl:newVariableInstance ref="delim">{ ../hdr/d }</dfdl:newVariableInstance> We need to specify whether $delim in the first annotation is referring to that variable before the new instance is created, or after. I suggest that before is more intuitive, as that is lexical order. Note however, that this means: <dfdl:newVariableInstance ref="prefix">{ fn:concat($prefix, "_", fn:name()) }</dfdl:newVariableInstance> is allowed and is not recursion. The expression is referring to $prefix from the enclosing scope, and then initializing a new instance of $prefix for the scope contained by this schema component. The same logic applies to dfdl:setVariable annotations. The order needs to be controlled by the user. I suggest the fix for this issue is as follows: Errata 3.20, 3.21, and Errata 3.25 must be modified (and the corresponding sections of the spec) For errata 3.20, and errata 3.21 the sentence: "However, the order of execution among them is not specified. Schema authors can insert sequences to control the timing of evaluation of statements more precisely." is replaced by: "The order of execution is specified in errata 3.25." Errata 3.25 is modified. Numbered item 3 of both the first list and second list is replaced by: 3. dfdl:setVariable(s) - in lexical order Numbered item 2 of the second list is replaced by: 2. dfdl:newVariableInstance(s) - in lexical order These two paragraphs are added below the numbered lists to clarify what 'lexical order' means. The dfdl:setVariable annotations at any one annotation point of the schema are always executed in lexical order. However, dfdl:setVariable annotations can also be found in different annotation points that are combined into the resolved set of annotations for one schema component. In this case, the order of execution of the dfdl:setVariable statements from any one annotation point remains lexical, but it is unspecified what the order of execution is across dfdl:setVariable statements coming from different annotation points. The dfdl:newVariableInstance annotations at any one annotation point of the schema are always executed in lexical order. However, dfdl:newVariableInstance annotations can also be found in different annotation points that are combined into the resolved set of annotations for one schema component. In this case, the order of execution of the dfdl:newVariableInstance statements from any one annotation point remains lexical, but it is unspecified what the order of execution is across dfdl:newVariableInstance statements coming from different annotation points. ---------------------- 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>

2 2

OGF DFDL WG Call Agenda 2013-10-01
by Steve Hanson 01 Oct '13

01 Oct '13

Please find agenda for call on Redmine at http://redmine.ogf.org/dmsf_files/13131?download= Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

new public comment: byteOrder not sufficient. Need bitOrder.
by Mike Beckerle 30 Sep '13

30 Sep '13

Please see http://redmine.ogf.org/boards/15/topics/43 This is a big stumbling block for us and our customers with the current draft. 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>

2 2

OGF DFDL WG Call Minutes 2013-09-24
by Steve Hanson 25 Sep '13

25 Sep '13

Please find minutes from the above call at http://redmine.ogf.org/dmsf_files/13130?download= Public Comment The following set are now in Public Comment until 15th October. Revised DFDL 1.0 Specification: https://redmine.ogf.org/issues/117 DFDL Experience Document 1 (Spec Errata): https://redmine.ogf.org/issues/118 DFDL Experience Document 2 (Action 140): https://redmine.ogf.org/issues/119 Please download, review and create comments as necessary. Please note item 8 in the minutes which proposes how to flag a public comment as resolved. Regards Steve Hanson Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

OGF DFDL WG Call Agenda 2013-09-24
by Steve Hanson 24 Sep '13

24 Sep '13

Please find agenda for call on Redmine at http://redmine.ogf.org/dmsf_files/13130?download= Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Fw: questions on setVariable
by Steve Hanson 24 Sep '13

24 Sep '13

For discussion on today's WG call... Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 24/09/2013 14:09 ----- From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com>, Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org> Date: 11/09/2013 15:36 Subject: Re: [DFDL-WG] questions on setVariable Mike, I have several email threads that track the original design discussion for action 186. You originally wrote down an algorithm for combining statement annotations into an ordered list, but then the next version scrapped that and proposed the current scheme. I think there must have been some reason for this? Are we just talking setVariable here, or also newVariableInstance and assert as well? If so would the ordering rules be the same within, and across, annotation points? A couple of users have asked about short form versions of statement annotations. Imposing an execution order is not compatible with this. This was discussed in one of the action 186 emails. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: Steve Hanson/UK/IBM@IBMGB, Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org> Date: 11/09/2013 14:48 Subject: Re: [DFDL-WG] questions on setVariable It is when there is more than one setVariable at one single annotation point that I believe they should definitely execute in lexical order. I am much less worried about across different annotation points that get resolved together which is what the Errata was clarifying. My preference would be this: If an element ref has 2 setVariable statements for variables A, B, and the element declaration has setVariable statements for variables X, Y, then ABXY, AXBY, AXYB, XYAB are all possible interleavings, but A is always before B, and X is always before Y so execution is always consistent with lexical order. I want to just clarify the hole we've left by not being tight enough about specifying the order of this evaluation of setVariables within or across annotation points in a resolved set. I can build a completely non-deterministic schema: <defineVariable name="x" defaultValue="1"/> <defineVariable name="y" defaultValue="2"/> <defineVariable name="z" defaultValue="0"/> <group name="coinFlip"/> <choice> <sequence> <annotation><appinfo> <dfdl:setVariable name="x" value="{ if ($y = 2) then 5/$z else 3 }"/>  <dfdl:setVariable name="y" value="1"/> </appinfo></annotation> <element name="nonLexicalOrder" type="string" dfdl:inputValueCalc="{ '' }"/> </sequence> <element name="lexicalOrder" type="string" dfdl:inputValueCalc="{ '' }"/> </choice> </group> The above group definition illustrates how we can test what order a particular implementation executes these setVariable statements. You get <lexicalOrder/> or <nonLexicalOrder/> depending on what the implementation does. It could even vary from run to run for one implementation if the implementation is using a hash implementation that is using different random seeds at different times. It could even vary within a run, if this group is reused several times in the schema. Now, why would somebody write this, I don't know, but it does illustrate the hole in the spec. Certainly it would be better if DFDL could not express things like this. computing x reads the value of y. If the assignment to y has not yet happened, then we get a processing error when we divide by zero. This can cause backtracking, and the schema will effectively dodge the SDE that is supposed to happen to prevent this sort of assignment-timing stuff. This doesn't fix the problem entirely. I think our current 'non-specification' of the precise order here even across annotation points was a bit of a cop-out. 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 Wed, Sep 11, 2013 at 6:26 AM, Steve Hanson <smh(a)uk.ibm.com> wrote: "I think the execution order needs to be specific within the annotations at one annotation point." The problem is that action 186 allowed scenarios like setVariable annotations simultaneously on an element ref, its global element and the element's simple type (*). So there is no longer 'one annotation point', there are multiple. That's when we formalised the concept of a 'resolved set of annotations' for a component, and stated that for all annotations of the same kind (**) in that set, the order of execution is not defined. We also state schema authors can insert sequences to provide more precise control over when annotations are executed. Several reasons for this. Is the lexical order of elements in appinfos, or of multiple appinfos, guaranteed in XSDL? If not then an editor could serialize appinfos or their content in any order. We also wanted to reserve the right to add explicit timing control in the future. And it made implementations easier. IBM DFDL 1.0.3 has been out in the field with this support since 1Q 2013. Tim, can you say what the execution order is for a resolved set of setVariables please? Or can we not tell because of the model? (*) Must be different variables, else SDE. (**) Asserts and discriminators with testKind 'pattern' are a different 'kind' from those with 'expression', for this purpose. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Suman Kalia <kalia(a)ca.ibm.com> To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com>, Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org>, "dfdl-wg-bounces(a)ogf.org" <dfdl-wg-bounces(a)ogf.org>, Steve Hanson/UK/IBM@IBMGB Date: 10/09/2013 19:23 Subject: Re: [DFDL-WG] questions on setVariable Mike - In the use case hilited by Jonathan where 2 annotations are defined on the same point. I would suggest the execution order to be based on the lexical order i.e. the order in which annotations appear.. Suman Kalia IBM Canada Lab WMB Toolkit Architect and Development Lead Tel: 905-413-3923 T/L 313-3923 Email: kalia(a)ca.ibm.com For info on Message broker http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.h… From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: Steve Hanson <smh(a)uk.ibm.com>, Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org>, "dfdl-wg-bounces(a)ogf.org" <dfdl-wg-bounces(a)ogf.org> Date: 09/10/2013 02:14 PM Subject: Re: [DFDL-WG] questions on setVariable Sent by: dfdl-wg-bounces(a)ogf.org 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 On Tue, Sep 10, 2013 at 1:50 PM, Steve Hanson <smh(a)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 IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: "Cranford, Jonathan W." <jcranford(a)mitre.org>, Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org> Date: 10/09/2013 18:23 Subject: Re: [DFDL-WG] questions on setVariable Sent by: dfdl-wg-bounces(a)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 Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy On Tue, Sep 10, 2013 at 12:53 PM, Cranford, Jonathan W. < jcranford(a)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/"> <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/"> <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) -- dfdl-wg mailing list dfdl-wg(a)ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg -- dfdl-wg mailing list dfdl-wg(a)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 -- dfdl-wg mailing list dfdl-wg(a)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 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

1 0