James - answers in-line below.

Regards

Steve Hanson
Architect, IBM Data Format Description Language (DFDL)
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848



From:        "Garriss Jr., James P." <jgarriss@mitre.org>
To:        "dfdl-wg@ogf.org" <dfdl-wg@ogf.org>,
Date:        08/10/2013 15:21
Subject:        [DFDL-WG] How do I preserve order in an unordered list?
Sent by:        dfdl-wg-bounces@ogf.org

---

(Sent on behalf of Roger Costello)
 
Hi Folks,
 
I am trying out the sequenceKind="unordered" property.
 
I created this simple test:
 
    <xs:element name="Test">
        <xs:complexType>
            <xs:sequence dfdl:sequenceKind="unordered" dfdl:separator="%SP;">
                <xs:element name="A" type="xs:string" dfdl:initiator="A:" />
                <xs:element name="B" type="xs:string" dfdl:initiator="B:" />
            </xs:sequence>
        </xs:complexType>
    </xs:element>
 
That schema says the input data must consist of A:___ and B:___, in any order.
 
Here is sample input:
 
   B:Cat A:Dog
 
I processed the input using the schema and here is the result that I got from Daffodil:
 
    <Test>
        <A>Dog</A>
        <B>Cat</B>
    </Test>
 
Notice that the order of the input data changed in the result XML. This was quite surprising to me.
 
Upon consulting the DFDL specification, it appears that the exhibited behavior is expected:
 
            ... a DFDL processor must sort the members of an
            unordered group into schema order when parsing.
 
QUESTIONS:
 
1. Is this really the desired behavior? I would not expect parsing to alter the order of any data. From my XML Schema experience, I would be shocked if an XML Schema validator altered the order of markup in XML instances simply because the XML Schema specified <all> (unordered sequence).

SMH: Yes it is the intended behaviour. It's because this is not xs:all, but xs:sequence with a DFDL annotation. As far as XSDL is concerned, it is a xs:sequence so the elements must appear in the sequence order (otherwise validation will fail). The original intent was to use xs:all but it imposes the restriction that maxOccurs = 1 on the elements in the group, precluding repeats, which was felt too restrictive, so it was not included in the DFDL subset of XSDL.

2. If we grant that this really is the desired behavior, then how do I create an unordered sequence in which DFDL parsing preserves the order of the data? In the above example, if the input data lists B:Cat first and A:Dog second, then how do I get that order preserved in the result XML?

SMH: In DFDL 1.0 you use xs:choice within a repeating element. I agree this is not ideal but it does preserve the order, at the expense of introducing a parent element into the infoset.  The latest revision of the DFDL spec is in Public Comment, you are very welcome to create a comment on the OGF site if you feel that xs:all should be supported - the link is http://redmine.ogf.org/projects/editor-pubcom/boards/15.

 
/Roger--
 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