Mike, you asked this same question on 1st
December, and I responded with the following ... sounds like it got lost
in the Christmas post :)
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.
I will forward you the complete thread.
Regards
Steve Hanson
IBM Hybrid Integration, Hursley, UK
Architect, IBMDFDL
Co-Chair, OGFDFDL Working Group
smh@uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
Note: I work Tuesday to Friday
From:
"Mike Beckerle"
<mbeckerle@apache.org>
To:
"DFDL-WG"
<dfdl-wg@ogf.org>
Date:
25/01/2022 17:47
Subject:
[EXTERNAL] [DFDL-WG]
revisit: nillable complex types and %ES restriction
Sent by:
"dfdl-wg"
<dfdl-wg-bounces@ogf.org>
The Daffodil user community is complaining about the DFDL
v1.0 restriction that nillable complex types can only have %ES; (empty
data) as their nilled representation.
Multiple important data standards find this restriction
quite awkward.
It has significant negative impact on usability because
it eliminates polymorphism of paths.
The path needed to refer to an element value has different
ending element path steps depending on whether it is nilled or not.
The value of having DFDL create an XML infoset is lost
if something as basic as this cannot be done in such a way that path expressions
work alike to how they would work in regular XML/XSD.
Is there a significant reason why this restriction cannot
be lifted?
If not we would probably plan to define a dfdlx namespace
property that can be used to enable this alternate behavior, and then we
could prototype this new fuctionality in Daffodil and propose this for
DFDL 2.0 revision.
--
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