What is Rationale why Nillable complex type elements can only have '%ES; ' as their dfdl:nilValue property
DFDL has this seemingly ad-hoc restriction. Users naturally want to model a complex element where "-" (dash) means the whole complex element is nilled, and if not "-" then we parse and produce a complex element. What is the rationale for this restriction?
See spec section 13.15. "to avoid the concept of a complex element having a value, which does not exist in DFDL". The parser would not know to treat the '-' as the nil value for the complex element, or the content of the first child? Allowing just %ES; avoids that. 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: "Mike Beckerle" <mbeckerle.dfdl@gmail.com> To: "DFDL-WG" <dfdl-wg@ogf.org> Date: 01/12/2021 21:07 Subject: [EXTERNAL] [DFDL-WG] What is Rationale why Nillable complex type elements can only have '%ES; ' as their dfdl:nilValue property Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org> DFDL has this seemingly ad-hoc restriction. Users naturally want to model a complex element where "-" (dash) means the whole complex element is nilled, and if not "-" then we parse and produce a complex element. What is the rationale for this restriction? -- 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
I guess I really don't see the need for the restriction. We do need a restriction for complex types that nilKind must be 'literalValue' or 'literalCharacter', not 'logicalValue' because there are no logical values for complex types. But literalValue and literalCharacter are representational. They're not about the value of an element. The representation of the complex type can be nilled with a nil representation of "-" without introducing any concept of "value" for the complex type element. Processing always proceeds to check the nil representation first, before checking anything else, and has to even now, given that we do allow %ES; as nil value for a complex type element. Did this %ES; only policy stem from the fact that we didn't really understand (early on) that nilled is an orthogonal non-value flag in the infoset elements? The fact that the workaround is this: <choice> <element name="noValue" type="xs:string" dfdl:lengthKind="explicit" dfdl:length="0" dfdl:initiator="-"/> <element name="myComplexType"> .... non nillable complex type definition .... </element> </choice> essentially this argues that the nil representation can be checked for first, and there's no real reason why the element of complex type can't be nillable with nilValue "-". On Wed, Dec 1, 2021 at 4:39 PM Steve Hanson <smh@uk.ibm.com> wrote:
See spec section 13.15. "to avoid the concept of a complex element having a value, which does not exist in DFDL". The parser would not know to treat the '-' as the nil value for the complex element, or the content of the first child? Allowing just %ES; avoids that.
Regards
Steve Hanson
IBM Hybrid Integration, Hursley, UK Architect, *IBM DFDL* <http://www.ibm.com/developerworks/library/se-dfdl/index.html> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/> *smh@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848 mob:+44-7717-378890 Note: I work Tuesday to Friday
From: "Mike Beckerle" <mbeckerle.dfdl@gmail.com> To: "DFDL-WG" <dfdl-wg@ogf.org> Date: 01/12/2021 21:07 Subject: [EXTERNAL] [DFDL-WG] What is Rationale why Nillable complex type elements can only have '%ES; ' as their dfdl:nilValue property Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org> ------------------------------
DFDL has this seemingly ad-hoc restriction.
Users naturally want to model a complex element where "-" (dash) means the whole complex element is nilled, and if not "-" then we parse and produce a complex element.
What is the rationale for this restriction? -- 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
I need to do some archaeology here but I'm fairly sure it is to do with our rules for establishing representation. To establish representation, you need to have extracted the data from the bitstream using lengthKind. The only length that makes sense for a complex element is zero, which is why only %ES; is allowed. (Note that a complex element with lengthKind='implicit' and nillable='true' is a SDE). Your suggestion of treating nil value on a complex element as a delimiter sidesteps that nicely but scuppers the algorithm for establishing representation, and possibly known-to-exist versus known-not-to-exist. I don't have time right now to do the archaeology, but this is at best a candidate for 2.0, and definitely not an erratum on 1.0. It certainly wasn't an ad-hoc restriction. 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: "Mike Beckerle" <mbeckerle.dfdl@gmail.com> To: "Steve Hanson" <smh@uk.ibm.com> Cc: "DFDL-WG" <dfdl-wg@ogf.org> Date: 01/12/2021 22:08 Subject: [EXTERNAL] Re: [DFDL-WG] What is Rationale why Nillable complex type elements can only have '%ES; ' as their dfdl:nilValue property I guess I really don't see the need for the restriction. We do need a restriction for complex types that nilKind must be 'literalValue' or 'literalCharacter', not 'logicalValue' because there are no logical values ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd I guess I really don't see the need for the restriction. We do need a restriction for complex types that nilKind must be 'literalValue' or 'literalCharacter', not 'logicalValue' because there are no logical values for complex types. But literalValue and literalCharacter are representational. They're not about the value of an element. The representation of the complex type can be nilled with a nil representation of "-" without introducing any concept of "value" for the complex type element. Processing always proceeds to check the nil representation first, before checking anything else, and has to even now, given that we do allow %ES; as nil value for a complex type element. Did this %ES; only policy stem from the fact that we didn't really understand (early on) that nilled is an orthogonal non-value flag in the infoset elements? The fact that the workaround is this: <choice> <element name="noValue" type="xs:string" dfdl:lengthKind="explicit" dfdl:length="0" dfdl:initiator="-"/> <element name="myComplexType"> .... non nillable complex type definition .... </element> </choice> essentially this argues that the nil representation can be checked for first, and there's no real reason why the element of complex type can't be nillable with nilValue "-". On Wed, Dec 1, 2021 at 4:39 PM Steve Hanson <smh@uk.ibm.com> wrote: See spec section 13.15. "to avoid the concept of a complex element having a value, which does not exist in DFDL". The parser would not know to treat the '-' as the nil value for the complex element, or the content of the first child? Allowing just %ES; avoids that. 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: "Mike Beckerle" <mbeckerle.dfdl@gmail.com> To: "DFDL-WG" <dfdl-wg@ogf.org> Date: 01/12/2021 21:07 Subject: [EXTERNAL] [DFDL-WG] What is Rationale why Nillable complex type elements can only have '%ES; ' as their dfdl:nilValue property Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org> DFDL has this seemingly ad-hoc restriction. Users naturally want to model a complex element where "-" (dash) means the whole complex element is nilled, and if not "-" then we parse and produce a complex element. What is the rationale for this restriction? -- 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 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 (2)
-
Mike Beckerle -
Steve Hanson