James, if you look in the trace viewer
and work back to the element in question, I suspect that you will see an
error like:
CTDP3138E: An unexpected
initiator was found for an empty element
DFDL lets you specify what the syntax
is for an empty element, using a property called dfdl:emptyValueDelimiterPolicy
here. It is probably set to 'none'. If you set it to 'both' then the parser
will expect to find an initiator and terminator when the content is empty.
Note that eliminates the need for the choice - you just have a single element
with lengthKind 'delimited' and emptyValueDelimiterPolicy set appropriately.
The current behaviour in IBM DFDL when
it finds an empty xs:string is to give an error for a required (minOccurs
'1') element, or to not add anything to the infoset for an optional (minOccurs
'0') element. However, there is an errata in this area which has just been
concluded, which changes this behaviour for xs:string so that a zero-length
xs:string is added to the infoset under certain circumstances. So in order
to guide you down the right path, I need to know a bit more info. Specifically,
what do you want ideally to appear in the infoset for the <> case?
A zero length string, or nothing at all, or the special value 'nil', or
a default value? And what would you want to appear when the infoset was
serialized: <> or is nothing also acceptable?
Regards
Steve Hanson
Architect, Data Format Description Language (DFDL)
Co-Chair, OGF
DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848
From:
"Garriss Jr.,
James P." <jgarriss@mitre.org>
To:
"dfdl-wg@ogf.org"
<dfdl-wg@ogf.org>,
Date:
01/03/2013 20:10
Subject:
[DFDL-WG] Empty
element with initiator and terminator
Sent by:
dfdl-wg-bounces@ogf.org
I have an element that can be one of two
things, either:
< string >
Or
<>
So I modeled this as a choice. For
the first choice, I made it a string with < and > being the initiator
and terminator. Works great.
For the second choice, I also made it a
string with < and > being the initiator and terminator, and I set
the length kind to explicit and the length to 0. That seems obvious
enough. But, alas, that causes errors in parsing. Nothing I
do for this seemingly simple construct works. There must be some
design pattern here that I am missing.
Ideas?
TIA--
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