default branch for choice by dispatch (action 327)

[mbeckerle]

Default branch to be identified by dfdl:choiceBranchKey="" (empty string).

This could also be an erratum on DFDL v1.0 because it is an upward compatible change.

[mbeckerle]

An explicit property is better.

Property dfdl:choiceBranchDefault="true" allowed on one branch.

This can also be combined with dfdl:choiceBranchKey so that the same branch can be selected for specific dispatch keys, and also be used as the default branch if desired. (This avoids a need to duplicate a branch for this use case.)

Implementations can implement a dfdlx:choiceBranchDefault property in advance of DFDL v2.0.

[smhdfdl]

@mbeckerle

Should be dfdl:choiceBranchDefault="yes" as in DFDL we use "yes"/"no" and not "true"/"false". Or was that deliberate?

I think it is clearer if a choice branch has either dfdl:choiceBranchKey or dfdl:choiceBranchDefault. You don't need to duplicate branches - the point of the default branch is you have a single branch for all those keys you are silent about. So just be silent about all the keys that require the default processing.

Let's try and state the details and see if anything gets flushed out...

• It must not appear with dfdl:choiceBranchKey.
• It is a Schema Definition Error if the value of the property is anything other than "yes".
• It is a Schema Definition Error if more than one choice branch specifies the property.
• It is not possible to place this property in scope on a dfdl:format annotation.
• Annotation: dfdl:element, dfdl:sequence, dfdl:choice, dfdl:group

Plus we need to update the usage conditions in both dfdl:choiceBranchKey & dfdl:choiceDispatchKey.

Two things jump out at me:

1. A lot of spec change for a small delta to the behaviour.
2. Only one allowable value for this property. We don't have any other property like that.

That says to me that using a separate property is the wrong approach, and we should use either dfdl:choiceBranchKey="" or dfdl:choiceBranchKey="some-reserved-value". Either are a more natural fit than a separate property.

[mbeckerle]

We do have a clear use case for a branch with both specific choice branch key values which is also the default branch.

Comes up when you have 2 levels of dispatch e.g., something like

<choice dfdl:choiceDispatchKey="{ $tns:key }">
    <sequence dfdl:choiceBranchKey="A B C" >
       <element ... something needed for all of A, B, C cases, but not D, E, F />
       <choice dfdl:choiceDispatchKey="{ $tns:key }">
            <element dfdl:choiceBranchKey="A" ..../>
            <element dfdl:choiceBranchKey="B" ..../>
            <element dfdl:choiceBranchKey="C" ..../>
        </choice>
    </sequence>
   <sequence dfdl:choiceBranchKey="D E F default">
       <sequence something needed for all these situations>
          ...
       </sequence>
       <choice dfdl:choiceDispathKey="{ $tns:key }">
            <element dfdl:choiceBranchKey="D" ..../>
            <element dfdl:choiceBranchKey="E" ..../>
            <element dfdl:choiceBranchKey="F" ..../>
            <sequence dfdl:choiceBranchKey="default">
                 ...
            </sequence>
        </choice>
   </sequence>
</choice>

The real situation is a bit more compelling because the inner choices are in separate named groups from the outer choice so the separation of concerns is clearer. The outer choice is dealing with categories of things, the inner ones with specific individual cases.

That throws a wrench in the works of using dfdl:choiceBranchKey="" to designate a default branch because there's no way to specify that and some distinct key values.

Another possibility is to add a property on xs:choice dfdl:choiceDispatchDefaultKey="dfdl:default" (or any other string value, but not empty string).

This designates that specific string to be the branch key value used to label a default branch if a default branch is desired.

One need not specify a default branch, but one may do so by using this default value as one of the dfdl:choiceBranchKeys for that branch.

This dfdl:choiceDispatchDefaultKey property would probably just go into a global scope as "default" or maybe a clumsier but less likely to conflict value like "dfdl:default", but could be changed if there was any conflict with the existing branch keys.

[smhdfdl]

In your example, you are showing exactly the second suggestion I made in my comment above .... use a reserved value for dfdl:choiceBranchKey ... you have called it 'default' but we'd need something different in practice.

dfdl:choiceBranchKey="D E F default"

Hang on, I've just noticed my suggestion has gone awol ... GitHub MarkDown and its dislike of < and > ... ok I've edited it now. Should make more sense :)

[mbeckerle]

Ah, yes I see now that this reserved value was in your first comment.

Do you think we can get away with just picking a string for this, or do you think we need the ability for schema authors to specify the string to be used?

[smhdfdl]

I think we can get away with picking a string for this.

But I still feel it is unnecessary and empty string is sufficient. I can trivially change your example above to that below and have the exact same behaviour, and use a comment to self-document.

<choice dfdl:choiceDispatchKey="{ $tns:key }">
    <sequence dfdl:choiceBranchKey="A B C" >
       <element ... something needed for all of A, B, C cases, but not D, E, F />
       <choice dfdl:choiceDispatchKey="{ $tns:key }">
            <element dfdl:choiceBranchKey="A" ..../>
            <element dfdl:choiceBranchKey="B" ..../>
            <element dfdl:choiceBranchKey="C" ..../>
        </choice>
    </sequence>
   <!-- D, E, F and any others -->
   <sequence dfdl:choiceBranchKey="">
       <sequence something needed for all these situations>
          ...
       </sequence>
       <choice dfdl:choiceDispatchKey="{ $tns:key }">
            <element dfdl:choiceBranchKey="D" ..../>
            <element dfdl:choiceBranchKey="E" ..../>
            <element dfdl:choiceBranchKey="F" ..../>
            <sequence dfdl:choiceBranchKey="">
                 ...
            </sequence>
        </choice>
   </sequence>
</choice>

[mbeckerle]

Per call 2023-01-05

Use a QName token such as "dfdl:default" as a reserved token to identify the default branch.

Steve suggested the term "default" is so heavily overloaded in DFDL that we should use some other term.

Looking for synonyms of the word default doesn't suggest anything useful.

Perhaps dfdl:otherwise, dfdl:other, dfdl:noMatch, dfdl:notABranchKey, dfdl:noBranch

[mbeckerle]

Per call 2023-01-19

Suggest dfdlx:default is sufficient. It's an extension for the time being anyway.