I like your forced failure device in your extension choice object. Sounds like we're inconsistent in the spec as to whether an xs:choice can be empty or not. Having no branches is inconsistent with the position that all branches cannot have minOccurs='0'. The more conservative design choice here is to disallow empty choices. ...mike On Mon, Feb 25, 2013 at 10:01 AM, Steve Hanson <smh@uk.ibm.com> wrote:
The DFDL spec says that all branches in an xs:choice must not have minOccurs '0' and if all branches are processed without a match then it is a processing error. But the DFDL spec also allows the creation of an empty xs:choice, that is, a choice without any branches at all. Some questions arise:
1) What happens when choiceLengthKind is 'explicit' - SDE ? Insist that choiceLength is '0' ?
2) What happens if choiceBranchRef is specified ?
3) Assuming any syntax matches, an empty choice always parses successfully. Read on...
I have been using an empty choice for modeling data formats where user-defined extensions are permitted. This was the mechanism agreed upon by the WG to model this scenario in the absence of xs:any support in DFDL 1.0. Here's an example from a schema that models the TLOG retail format:
*<xsd:choice>* <xsd:element *ref*="TransactionRecord00"/> <xsd:element *ref*="TransactionRecord01"/> <xsd:element *ref*="TransactionRecord04"/> <xsd:element *ref*="TransactionRecord05"/> <xsd:element *ref*="TransactionRecord98"/> <xsd:group *ref*="choice_Custom"/> *</xsd:choice>*
<!-- Group for all user-defined records --> <xsd:group name="choice_Custom"> *<xsd:choice>* <!-- Insert elements here -->
*</xsd:choice>* *</xsd:group>*
The intent is that the user adds his own records in the choice_Custom group. If an unknown record is parsed that fails to match any of the pre-defined records and any of the user-defined records, it will cause a processing error.
However that didn't actually work. Because choiceCustom is initially empty, it will parse successfully against any input and in doing so discriminate the outer choice, meaning the processing error is not thrown. As soon as an element is added to choice_Custom, then it behaves as originally intended - an unknown record causes a processing error in choice_Custom, so the outer choice never discriminates.
To work around this I added an assert to the choice to ensure it fails when empty.
<!-- Group for all user-defined records --> <xsd:group name="choice_Custom"> *<xsd:choice>* <!-- Insert elements here -->
<!-- If we get here ensure choice fails --> *<xsd:sequence>* *<xsd:annotation>*<xsd:appinfo source=" http://www.ogf.org/dfdl/"> * <dfdl:assert>{fn:false()} </dfdl:assert>* *</xsd:appinfo></xsd:annotation>* *</xsd:sequence>* *</xsd:choice>* *</xsd:group>*
So is an empty choice a genuinely useful construct to allow? It didn't actually help my scenario in 3). Are there any where it would make sense?
Regards
Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/> IBM SWG, Hursley, UK* **smh@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848 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
-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com