[DFDL-WG] clarification - dfdl:choiceDispatchKey does not specify forward-reference restrictions

[Steve Hanson]

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 at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890



From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     "dfdl-wg at ogf.org" <dfdl-wg at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20170830/b4ee77b9/attachment.html>