[DFDL-WG] How do I preserve order in an unordered list?

[Garriss Jr., James P.]

(On behalf of Roger Costello)


Ø  Erase the DFDL annotation: now your model has a <sequence>

Ø  containing first element A, then element B. If we allowed those

Ø  to be in the other order your infoset would not be valid for your

Ø  model.

My goodness, sequenceKind="unordered" is a strange beast. So it means:

            The input data can be in any order, but I (the parser) am
            going to reorder the data into the sequence listed here (in
            the schema).

That certainly is contrary to unordered lists in XML Schema.


Ø  If you want to preserve the order information you need to model

Ø  that differently. Perhaps via an array with an element containing a

Ø  choice inside it.

Well, that's what James has had to do in his email schema. He introduced a bogus array element to compensate for the lack of unordered lists. The reason we pushed for sequenceKind="unordered" is that we thought it allowed us to create unordered lists (with order preserved). Apparently we were mistaken.

So to recap: there is no way to create an unordered list, with order preserved, without introducing a bogus wrapper element.

Bummer.

/Roger


From: Mike Beckerle [mailto:mbeckerle.dfdl at gmail.com]
Sent: Tuesday, October 08, 2013 11:06 AM
To: Garriss Jr., James P.
Cc: dfdl-wg at ogf.org
Subject: Re: [DFDL-WG] How do I preserve order in an unordered list?


Yes, the behavior is entirely intentional.

Erase the DFDL annotation: now your model has a <sequence> containing first element A, then element B. If we allowed those to be in the other order your infoset would not be valid for your model.
If you want to preserve the order information you need to model that differently. Perhaps via an array with a element containing a choice inside it.

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, Oct 8, 2013 at 10:21 AM, Garriss Jr., James P. <jgarriss at mitre.org<mailto:jgarriss at mitre.org>> wrote:
(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).

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?

/Roger

--
  dfdl-wg mailing list
  dfdl-wg at ogf.org<mailto:dfdl-wg at ogf.org>
  https://www.ogf.org/mailman/listinfo/dfdl-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20131008/2fb94c9f/attachment.html>