[DFDL-WG] Empty element with initiator and terminator

Tue Mar 5 09:26:34 EST 2013

Thank you Steve and Tim, your answers are very helpful.

> The current behaviour in IBM DFDL when it finds an empty xs:string is to give an error for a required (minOccurs '1') element

That is the behavior I am experiencing now, even with the emptyValueDelimiterPolicy set to none.

Mar 5, 2013 9:25:17 AM  error: CTDP3059E: Element 'PlainEmail' has minOccurs='1' and no default value but the input document contained only '0' occurrences.

That's not the behavior I expect or desire, as <> is completely valid input.

> 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

That would be more appropriate for my situation.

> 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?

Hmmm, I think a zero length string gives the correct sense.  Nil implies the value is unknown or not applicable, which is not true.  Nothing indicates there was no input, which is not true, as <> is a legal value.  Default value doesn't make sense.

> And what would you want to appear when the infoset was serialized: <> or is nothing also acceptable?

<>, because we need to reconstruct the input.

So I guess I know how to model this, I just need to wait for MTBK to be updated to reflect this errata.

From: Steve Hanson [mailto:smh at uk.ibm.com]
Sent: Monday, March 04, 2013 4:40 AM
To: Garriss Jr., James P.
Cc: dfdl-wg at ogf.org; dfdl-wg-bounces at ogf.org
Subject: Re: [DFDL-WG] Empty element with initiator and terminator

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<http://www.ogf.org/dfdl/>
IBM SWG, Hursley, UK
smh at uk.ibm.com<mailto:smh at uk.ibm.com>
tel:+44-1962-815848

From:        "Garriss Jr., James P." <jgarriss at mitre.org<mailto:jgarriss at mitre.org>>
To:        "dfdl-wg at ogf.org<mailto:dfdl-wg at ogf.org>" <dfdl-wg at ogf.org<mailto:dfdl-wg at ogf.org>>,
Date:        01/03/2013 20:10
Subject:        [DFDL-WG] Empty element with initiator and terminator
Sent by:        dfdl-wg-bounces at ogf.org<mailto:dfdl-wg-bounces at 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 at ogf.org<mailto:dfdl-wg at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20130305/1663ab27/attachment.html>