[DFDL-WG] default case needed for choice-by-dispatch

Fri Jul 15 10:31:26 EDT 2022

Hi Mike

After our discussion the WG call I now see what I was missing. I have added the word outer to your description to make things clear.

I agree that this is a problem, if you need to distinguish between bad choice branch key and a good choice branch key that then throws an error when parsing the branch.   The IBM SWIFT schemas use direct dispatch choice but don't need to make the distinction and so don't need a default branch. The IBM EDIFACT schemas do make this distinction but don't use direct dispatch choice, they use a discriminator (because the branch identifier is within each branch).

So, I agree that we need to provide a way to allow a default branch when using direct dispatch choice. However I think we can do that without a new property, either:

a) Do not specify dfdl:choiceBranchKey. I don't see this as error prone, the equivalent when using discriminators would be not to provide a discriminator on the final branch.

b) Use dfdl:choiceBranchKey="". You can't set that today (because it must be a DFDL String Literal)

Obviously a maximum of one branch can be so designated.  Note that the default branch does not have to be the last branch in schema declaration order, as the parser always jumps straight to a branch and never tries another.

Regards

Steve Hanson

IBM Integration, Hursley, UK
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
smh at uk.ibm.com<mailto:smh at uk.ibm.com>
tel:+44-7717-378890
Note: I work Tuesday to Friday

-----Original Message-----
From: Steve Hanson <smh at uk.ibm.com<mailto:Steve%20Hanson%20%3csmh at uk.ibm.com%3e>>
To: mbeckerle at apache.org<mailto:mbeckerle at apache.org>, DFDL-WG <dfdl-wg at ogf.org<mailto:DFDL-WG%20%3cdfdl-wg at ogf.org%3e>>
Subject: Re: [EXTERNAL] [DFDL-WG] default case needed for choice-by-dispatch
Date: Thu, 14 Jul 2022 14:53:01 +0100

Hi Mike

Are you sure about this?   The spec section 15.1.2 which describes direct dispatch choice says ...

"When a match is found, it is as if a dfdl:discriminator had evaluated to true on that branch. It is selected as resolution of the choice, and there is no backtracking to try other alternative selections if a Processing Error occurs."

I don't see why you are needing the extra discriminator, it sounds like this is a bug in Daffodil.

Regards

Steve Hanson

IBM Integration, Hursley, UK
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
smh at uk.ibm.com<mailto:smh at uk.ibm.com>
tel:+44-7717-378890
Note: I work Tuesday to Friday

-----Original Message-----
From: Mike Beckerle <mbeckerle at apache.org<mailto:Mike%20Beckerle%20%3cmbeckerle at apache.org%3e>>
Reply-To: mbeckerle at apache.org<mailto:mbeckerle at apache.org>
To: DFDL-WG <dfdl-wg at ogf.org<mailto:DFDL-WG%20%3cdfdl-wg at ogf.org%3e>>
Subject: [EXTERNAL] [DFDL-WG] default case needed for choice-by-dispatch
Date: Mon, 16 May 2022 11:57:54 -0400

I know this feature was discussed at one time. The priority of this has gone up for us substantially, as the idiom in DFDL v1.0 for a choice-by-dispatch to have a default case when the choiceDispatchKey doesn't match any choiceBranchKey
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd
I know this feature was discussed at one time.

The priority of this has gone up for us substantially, as the idiom in DFDL v1.0 for a choice-by-dispatch to have a default case when the choiceDispatchKey doesn't match any choiceBranchKey is far too complex.

This appears to be what is needed:

<!-- just a shorthand so we can discriminate true on one DFDL line -->
<group name="discriminateTrue">
        <sequence>
            <annontation><appinfo ...>
                 <dfdl:discriminator>{ fn:true() }</dfdl:discriminator>
            </appinfo></annotation>
        </sequence>
</group>

....
  <choice>
        <choice dfdl:choiceDispatchKey='{ ... dispatch key expr... }'>
            <sequence dfdl:choiceBranchKey="key1">
               <group ref="p:discriminateTrue"/>
                ... parse the key1 branch ....
            </sequence>
            ...
            <sequence dfdl:choiceBranchKey="keyN">
               <group ref="p:discriminateTrue"/>
                ... parse the keyN branch ....
            </sequence>
        </choice>
     <!-- default case below if the dispatch key does not match anything -->
     <element name="invalidKey" ....>
       ...
     </element>
  </choice>
.....

The need for a discriminator for the outer choice on every single branch of the inner choice is tedious at best. This is needed because if you don't have this discriminator, then the backtrack will choose the other outer choice alternative for any failure of a branch, not just no branch key match, and one will get a diagnostic that the branch key was not found when it was found but the subsequent parse failed.

This structure is too complex for DFDL schema authors to get right. A way to specify an additional choice branch which is the default to be used on no-match to the other branch keys, is needed.

An explicit dfdlx:choiceBranchDefault="yes" is one way to do this.

A final choice branch with no dfdl:choiceBranchKey would also work but seems too error-prone for my taste. A default case should be explicitly marked as such, even if we require it to be the last branch.

Mike Beckerle
Apache Daffodil PMC | daffodil.apache.org<http://daffodil.apache.org/>
OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl<http://www.ogf.org/ogf/doku.php/standards/dfdl/dfdl>
Owl Cyber Defense | www.owlcyberdefense.com<http://www.owlcyberdefense.com/>

--

  dfdl-wg mailing list

  dfdl-wg at ogf.org<mailto:dfdl-wg at ogf.org>

  https://www.ogf.org/mailman/listinfo/dfdl-wg

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20220715/9b09997e/attachment-0001.html>