[DFDL-WG] complex nillable ES restriction - more

Tue Jun 23 09:29:53 EDT 2015

Related to this, noted that the DFDL nil properties in section 13.15 all 
say:

        Annotation: dfdl:element(simpleType)

The only one that is applicable only to simple types is 
dfdl:useNilForDefault.

Regards

Steve Hanson
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh at uk.ibm.com
tel:+44-1962-815848

From:   Steve Hanson/UK/IBM
To:     Mike Beckerle <mbeckerle.dfdl at gmail.com>
Cc:     "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>
Date:   28/04/2015 10:15
Subject:        Re: [DFDL-WG] complex nillable ES restriction - more

Some more on this ...

Here's the words from section 13.15 of the spec:
DFDL allows elements of complex type to be nillable. However, to avoid the 
concept of a complex element having a value, which does not exist in DFDL, 
the only permissible nil value is the empty string, represented by the 
DFDL %ES; entity and using dfdl:nilKind 'literalValue'.

Here's the original words from experience document #2 on this. Note the 
lengthKind 'implicit' restriction.

For a complex element, length plus initiator and terminator enables the 
nil representation to be established (It is a schema definition error if a 
complex element is nillable ‘true’ and lengthKind ‘implicit’), but all 
other representations can only be determined by descending into the 
complex type for the element. If the descent returns successfully (that 
is, no unsuppressed processing error occurs) then the other 
representations may be established.

So ... if you can establish the length of the complex element up front 
then potentially you could check against any nil literal value. 

Such a check would be different from that for a simple element though, as 
pad characters are trimmed first, and those properties do not apply to 
complex elements. 

I am not sure about lengthKind 'delimited'. With the current ES only rule, 
the parser can look at the next byte and if it immediately finds an 
in-scope delimiter, it can match ES. If any nil literal value is allowed, 
the parser is going to have to scan.

Regards

Steve Hanson
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh at uk.ibm.com
tel:+44-1962-815848

From:   Steve Hanson/UK/IBM
To:     Mike Beckerle <mbeckerle.dfdl at gmail.com>
Cc:     "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>
Date:   28/04/2015 09:23
Subject:        Re: [DFDL-WG] complex nillable ES restriction

It's not an ad-hoc restriction. It's because a complex element has no 
value, so there are no DFDL properties to describe a value.

Regards

Steve Hanson
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh at uk.ibm.com
tel:+44-1962-815848

From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>
Date:   27/04/2015 19:06
Subject:        [DFDL-WG] complex nillable ES restriction
Sent by:        dfdl-wg-bounces at ogf.org

Right now complex elements can be nillable, but we have this ad-hoc 
restriction that says the nilValue can only be %ES;.

The rationale for this is unclear to me. Can we review what the rationale 
for this restriction was? Does anyone recall?

We have a format where the literal nil value for the complex type wants to 
be "%WSP*;-%WSP*;" that is, a hyphen, but with surrounding whitespace 
absorbed.

We can model this a different way, but the natural thing to do is to model 
it as suggested. 

(This also just happens to run on Daffodil - because we're not detecting 
this ad-hoc restriction - a bug)

Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | 
www.tresys.com
Please note: Contributions to the DFDL Workgroup's email discussions are 
subject to the OGF Intellectual Property Policy
--
  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/20150623/700d5662/attachment.html>