This was covered by erratum 5.60 and action 279.
279
Improve defaulting description to explicitly cover local groups (Mike)
28/4/15: Only talks about elements, should mention local sequence and choice.
12/5: Not discussed
23/6: Section 15.1.3 needs to say what happens when a choice branch does not contain any elements; such a choice branch is selected (but see action 280 below as minOccurs '0' might change this). Section 9.4 also needs updating to say what happens when local groups are found within a complex type.
11/8: Steve did some tests with IBM DFDL. Just need some words as above. Action assigned to Mike.
25/8: In progress
...
5/1/16: No progress
...
12/12/19: No further progress
9/1/20: Closed. Mike has created an erratum 5.60 for this, which Steve has reviewed.


5.60 Clarifications of Choice Branch Selection when Defaulting (Action 279)

Section 15.1.3 Insert at end of 1st paragraph.
"If the next element to unparse does not identify any branch of the choice, or there is no next element to unparse, then there must be a choice branch with no required elements and the first such branch would be selected for unparsing. A choice branch could consist only of a nest of model groups with no actual element content or only optional element content."

Section 9.4.3.2 Insert at end of final paragraph.
"If no choice branch is selected, then there must be a choice branch with no required elements, and the first such branch would be selected."

Bradd's re-ordering of the choice branches achieves the desired behaviour, as it makes the 'false' branch first and means it gets chosen as per the erratum.

Alternatively you can disambiguate by introducing an element as the root of each branch. That's what the last sentence in 15.1.3 means ... " To avoid any unintended behavior, all the children of a choice can be modeled as elements.".  It might not give you the ideal infoset though.

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
Note: I work Tuesday to Friday



From:        "Bradd Kadlecik" <braddk@us.ibm.com>
To:        Mike Beckerle <mbeckerle.dfdl@gmail.com>
Cc:        DFDL-WG <dfdl-wg@ogf.org>
Date:        20/03/2020 18:36
Subject:        [EXTERNAL] Re: [DFDL-WG] Clarification: Unparser choice branch selection (section15.1.3)
Sent by:        "dfdl-wg" <dfdl-wg-bounces@ogf.org>




My parser handles that by requiring the switching of the order of the sequence statements. The empty branch is taken as the first branch when no elements are found from other branches. I think that's in keeping with the spec. I of course defer to Steve tho.
Regards,

Bradd Kadlecik
z/TPF Development

Phone: 1-845-433-1573
E-mail: braddk@us.ibm.com
2455 South Rd
Poughkeepsie, NY 12601-5400
United States



Inactive hide details for Mike Beckerle ---03/20/2020 12:54:16 PM---We have choices like this: <choice>Mike Beckerle ---03/20/2020 12:54:16 PM---We have choices like this: <choice>

From: Mike Beckerle <mbeckerle.dfdl@gmail.com>
To: DFDL-WG <dfdl-wg@ogf.org>
Date: 03/20/2020 12:54 PM
Subject: [EXTERNAL] [DFDL-WG] Clarification: Unparser choice branch selection (section 15.1.3)
Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org>





We have choices like this:

<choice>
<sequence>
  <sequence dfdl:hiddenGroupRef="PI_true"/>

    <sequence>
     <element name="foo" minOccurs="0" ...../>
     <element name="bar" minOccurs="0" ..../>
  </sequence>

  <sequence dfdl:hiddenGroupRef="PI_false"/>

</choice>

PI_true and PI_false are presence indicator flags.

When unparsing, if you have element "foo" or "bar" in the infoset, then the first branch is selected, and the PI_true flag is unparsed.

The problem is when neither "foo" nor "bar" is in the infoset. Note that both are optional above.

In that case, we want the PI_false branch to be chosen.

So point 1: The DFDL spec (section 15.1.3)  is unclear about how a choice branch is chosen if it contains no visible element. 

Possible fix 1: One reasonable clarification might be that the first branch that admits no elements when unparsing would be chosen.

Possible fix 2: Another reasonable clarification would be that a branch with no possible elements is preferred to branches that have possible elements. If there is more than one such branch, the first would be chosen.

Maybe there are other possible fixes?

Daffodil currently is implementing possible fix 2, but that's not necessarily right. It maintains backward compatibility with older daffodil-oriented DFDL schemas.

If we decide Fix 1 is better, then we would have to put in a backward compatibility flag defaulting to true that enables users to continue to use schemas written as above, but we'd have to revise schemas like the above to reverse the order of the branches, and eventually flip the state of the flag to require use of these new reordered schemas.

Thoughts?

Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | www.owlcyberdefense.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://www.ogf.org/mailman/listinfo/dfdl-wg

--
 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