Agreed to defer to a future DFDL release.

Regards

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

From: Steve Hanson/UK/IBM
To: Mike Beckerle <mbeckerle.dfdl@gmail.com>,
Cc: dfdl-wg@ogf.org
Date: 19/11/2012 19:24
Subject: Re: [DFDL-WG] discriminators near PoU or not

Hi Mike,

I hit a similar scenario today with an EDIFACT message. There was an optional array containing a bunch of initiated records. I used 'initiatedContent' for the array's sequence, but needed to add an extra discriminator to stop an error from within one of the records from causing the parser to backtrack and conclude that the array occurrence was not there. Not easy to know where to put it.

One possibility is an 'all' attribute that says it resolves all points of uncertainty that are in scope?

Regards

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

From: Mike Beckerle <mbeckerle.dfdl@gmail.com>
To: dfdl-wg@ogf.org,
Date: 29/10/2012 01:25
Subject: [DFDL-WG] discriminators near PoU or not
Sent by: dfdl-wg-bounces@ogf.org

I thought this situation was worth discussing.

I have a bunch of messages. They all work like this:

<element name="messageName1">
<complexType>
<sequence>
   <element ref="boilerplateElt1" minOccurs="0"/>
   <element ref="boilerplateElt2" minOccurs="0"/>
   <sequence dfdl:initiator="MSG1">
       .... message specific elements go in here...
   </sequence>
   ... optional trailing boilerplates go here
</complexType>
</element>

There are hundreds of those.

These all are used in this way:

<element name="topLevel">
<complexType>
   <sequence>
     <element name="message" minOccurs="1" maxOccurs="unbounded">
       <complexType>
          <choice>
              <element ref="messageName1"/>
              <element ref="messageName2"/>
              ....
          </choice>
        </complexType>
    </element>
</sequence>
</complexType>
</element>

So, there are two points of uncertainty here. The choice, and the unbounded array surrounding it.

For each message, it is not until the sequence carrying the initiator, which is down inside the message structure, that we know for sure we've got this kind of message.

So currently each message element is designed to be used ONLY in the above context of two surrounding points of uncertainty, like so (same message format as above
but with TWO discriminators added).

<element name="messageName1">
<complexType>
<sequence>
   <element ref="boilerplateElt1" minOccurs="0"/>
   <element ref="boilerplateElt2" minOccurs="0"/>
   <sequence dfdl:initiator="MSG1">
      <annotation><appinfo...>
          
          <dfdl:discriminator>{ true() }</dfdl:discriminator>
          
          <dfdl:discriminator>{ true() }</dfdl:discriminator>
      </appinfo></annotation>
       .... message specific elements go in here...
   </sequence>
   ... optional trailing boilerplates go here
</complexType>
</element>

I'd love to have a better solution to this issue. But in the absence of one this works and achieves what I want which is that once it hits the initiator, we discriminate both which message we have, and we discriminate that we in fact have a message.

Interesting that I'd really prefer to discriminate them in the opposite order of their nesting. I could discriminate the array the the very start of the message. But I have no way to do that because the discriminators apply in inward-out nesting order, and the nearest enclosing PoU is the choice. So I have to discriminate that one first, and I can't discriminate that one until I see the initiator, which is later into the message.

Possible fixes/improvements: allow a label/id on each PoU, and allow referencing that label from a discriminator to say exactly which PoU you are discriminating. This makes the outward reference implied by a discriminator explicit. You still have the context issue, but it's not implied anymore, it is explicit. (This makes the problem like expressions with "../../.." that reach up and out of a construct. They are reaching up and out, but at least you can see directly that they are doing so.)

--
Mike Beckerle | OGF DFDL WG Co-Chair
Tel: 781-330-0412
-- 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

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