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@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 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@uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: "dfdl-wg@ogf.org" <dfdl-wg@ogf.org> Date: 27/04/2015 19:06 Subject: [DFDL-WG] complex nillable ES restriction Sent by: dfdl-wg-bounces@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@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