[DFDL-WG] revisit: nillable complex types and %ES restriction

[Steve Hanson]

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, IBM DFDL
Co-Chair, OGF DFDL Working Group
smh at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
Note: I work Tuesday to Friday 



From:   "Mike Beckerle" <mbeckerle at apache.org>
To:     "DFDL-WG" <dfdl-wg at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20220125/bfd85f7a/attachment-0001.html>