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@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@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848
From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@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@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@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