Clarification: Unparser choice branch selection (section 15.1.3)
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 <http://www.ogf.org/About/abt_policies.php>
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 2455 South Rd E-mail: braddk@us.ibm.com Poughkeepsie, NY 12601-5400 United States 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ogf.org_mailman_listinfo_dfdl-2Dwg&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=Gr_9muStjOfOwiy6fErdWcH5wgoRUAPlQRqBfOga1GA&m=erDuahYfFtpPq19AUm20nn4zZbLlx-LgSHrHU477jK4&s=_2Vtb18d20gKAnr9ddt7bJEZcCFCOIQcg57LZy61Lug&e=
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 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://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
participants (3)
-
Bradd Kadlecik -
Mike Beckerle -
Steve Hanson