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@uk.ibm.com
tel:+44-1962-815848
From: Steve Hanson/UK/IBM
To: Mike Beckerle
Cc: "dfdl-wg@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@uk.ibm.com
tel:+44-1962-815848
From: Steve Hanson/UK/IBM
To: Mike Beckerle
Cc: "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
To: "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
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