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