[DFDL-WG] Proposed Errata Language: Issue - DFDL Expressions may not return empty string for ...

[Mike Beckerle]

Here's some proposed errata language:

*The following properties descriptions are amended to include this
stipulation: When a DFDL Expression is used, it may not produce empty
string.

The affected properties are:**
*

   - *textBooleanTrueRep*
   - *textBooleanFalseRep*
   - *initiator*
   - * terminator*
   - *separator*


I did verify that the other properties that allow DFDL Expression to
compute a string do not need further clarification.

On Tue, Jan 10, 2012 at 11:52 AM, Steve Hanson <smh at uk.ibm.com> wrote:

> Hi Mike
>
> As will be minuted, we agreed on the WG call today that we disallow
> expressions that return empty string for properties where empty string
> turns off the property. Please can you take a look through the spec and see
> if any properties other than initiator, terminator, separator are impacted,
> then I can complete the errata.
>
> (I would expect that inputValueCalc and outputValueCalc are not affected
> by this errata, as empty string is a legal value for the element in
> question if it is of type xs:string).
>
> 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* <smh at uk.ibm.com>
> tel:+44-1962-815848
>
>
>
> From:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
> To:        dfdl-wg at ogf.org
> Date:        10/01/2012 08:06
> Subject:        [DFDL-WG] spec clarification needed: is
> dfdl:terminator='{ ...returns empty string ... }' allowed?
> Sent by:        dfdl-wg-bounces at ogf.org
> ------------------------------
>
>
>
>
> Let's use the example of terminator as a delimiter.
>
> If I provide an expression so that I can compute terminator at runtime, is
> it allowed to return empty string? I.e., equivalent to writing
> dfdl:terminator="" which is effectively "turning off" use of terminator?
>
> It seems very problematic to me if we allow this.  Nor do I think this
> generality is needed.
>
> We should clarify that for initiator/terminator/separator, if a runtime
> expression is used, then it must return at least one non-zero-length value.
> So using a runtime expression for a delimiter is effectively saying "yes
> there will be a delimiter", you are just not binding its specific value.
>
> I believe this runtime expression capability for delimiters was intended
> to allow the choice of the specific delimiter to be made based on data
> containing the value. This is common practice in data formats.
>
> However, turning on/off whether delimiters are present or not, is not
> something I anticipated, and it has far bigger implications for the format.
> I mean you really can't decide much about the data format statically if
> even the existence of delimiters as part of the format or not can be
> postponed to runtime.
>
> Comments?
>
> --
> Mike Beckerle | OGF DFDL WG Co-Chair
> Tel:  781-330-0412
> --
>  dfdl-wg mailing list
>  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
> *
>
>
>
>
>
>
>


-- 
Mike Beckerle | OGF DFDL WG Co-Chair
Tel:  781-330-0412
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20120116/89658191/attachment.html>