[DFDL-WG] What is Rationale why Nillable complex type elements can only have '%ES; ' as their dfdl:nilValue property

[Steve Hanson]

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 at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
Note: I work Tuesday to Friday 



From:   "Mike Beckerle" <mbeckerle.dfdl at gmail.com>
To:     "Steve Hanson" <smh at uk.ibm.com>
Cc:     "DFDL-WG" <dfdl-wg at 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 at 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 at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
Note: I work Tuesday to Friday 



From:        "Mike Beckerle" <mbeckerle.dfdl at gmail.com> 
To:        "DFDL-WG" <dfdl-wg at 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 at 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 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


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/20211202/6fc7dc41/attachment-0001.html>