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