The intent of choiceDispatchKey was that the expression could be evaluated then and there on the choice with no looking ahead. The motivating example was SWIFT due to the large number of branches in the main body choice, and its key occurs earlier. I'd not even considered a use case like your one. We could extend choiceDispatchKey, it would require that every branch was validated to ensure that an instance MUST ALWAYS contain the expression target. A candidate for DFDL 2.0 I think.

I have encountered formats like your one and have used discriminators. It is clearly inefficient though. More efficient would be using a discriminator with testKind="pattern" to avoid fully parsing the elements preceding the key.

If the content of each branch up to and including the key is identical, then those elements can be pulled out and placed ahead of the choice, but that might not give the desired infoset. In some circumstances the infoset can be fixed up using a hidden group and calculated values.

Regards

Steve Hanson

IBM Hybrid Integration, Hursley, UK
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
smh@uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890

From: Mike Beckerle <mbeckerle.dfdl@gmail.com>
To: "dfdl-wg@ogf.org" <dfdl-wg@ogf.org>
Date: 29/08/2017 19:30
Subject: [DFDL-WG] clarification - dfdl:choiceDispatchKey does not specify forward-reference restrictions
Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org>

The test expressions in dfdl:assert and discriminator both specify that they may refer to the value of this element or its descendents.

Hence, a test can refer to complex content down and inside the element.

Most other properties can refer only backward, and not to the value of the element on which they appear (as their values are likely needed in order to parse that data and get an element at all.)

However for dfdl:choiceDispatchKey, there is no description of what the expression may refer to.

There is a common use case for choices which is where the fields(s) that the choiceDispatchKey wants to inquire about are found at a fixed position inside each of the choice branches. Programming languages use offsets to reach forward into the data to retrieve these.

The only way this can be expressed in DFDL, without running into problems with polymorphic path steps, requires such elements to appear
as children of a sequence that is the root of each branch.

So for example:

<element name="msg">
   <complexType>
     <choice dfdl:choiceDispatchKey="{ ../msg/key }">
        <sequence dfdl:choiceBranchKey="1">
             ... stuff ...
             <element name="key" ..../>
            ... more stuff...
       </sequence>
        <sequence dfdl:choiceBranchKey="3">
             ... stuff ...
             <element name="key" ..../>
            ... more stuff...
       </sequence>
      .... and so on ...
   </choice>
</complexType>
</element>

This uses paths that reach down into the inside of each branch to obtain the key element.

So is this legal, or not?

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
-- dfdl-wg mailing list dfdl-wg@ogf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ogf.org_mailman_listinfo_dfdl-2Dwg&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=AJa9ThEymJXYnOqu84mJuw&m=fLChX9eN5c9Ba3kVdQufkMXEtNFMnCuB2SvDaAt3dAI&s=MGeuysvhY1tpT7VuKVVKbqWpNfdPJBzvbVwpo5MqPfw&e=

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