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@uk.ibm.com
tel:+44-1962-815848




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