[DFDL-WG] Clarification: Unparser choice branch selection (section 15.1.3)
Steve Hanson
smh at uk.ibm.com
Wed Apr 15 12:12:42 EDT 2020
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 at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
Note: I work Tuesday to Friday
From: "Bradd Kadlecik" <braddk at us.ibm.com>
To: Mike Beckerle <mbeckerle.dfdl at gmail.com>
Cc: DFDL-WG <dfdl-wg at 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 at 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 at us.ibm.com
2455 South Rd
Poughkeepsie, NY 12601-5400
United States
Mike Beckerle ---03/20/2020 12:54:16 PM---We have choices like this:
<choice>
From: Mike Beckerle <mbeckerle.dfdl at gmail.com>
To: DFDL-WG <dfdl-wg at 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 at 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 at ogf.org
https://www.ogf.org/mailman/listinfo/dfdl-wg
--
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=8_yWLuLBjSiO2vZNf-2246MbSceJDwqwOchlw9s5otM&s=kgvonakQcqaLS4NOOeSuJb8hDCLpCV6RCLrrTUMIabk&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/20200415/20201103/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20200415/20201103/attachment-0001.gif>
More information about the dfdl-wg
mailing list