[DFDL-WG] Proposed Errata Language: Issue - DFDL Expressions may not return empty string for ...
Steve Hanson
smh at uk.ibm.com
Tue Jan 17 05:52:34 EST 2012
Mike
I think you have highlighted a general deficiency in the spec.
When a property is a DFDL String Literal, or List of DFDL String Literal,
the spec is usually silent about the validity of empty string. The
assumption has always been that empty string is only allowed when
explicitly stated in the property description (such as for initiator,
terminator and separator). Hence for textBooleanTrue/FalseRep, empty
string is implicitly not permitted as a value. We should be explicit about
this in section 6.3.1, and say empty string not allowed as a value, unless
explicitly stated in the individual property description. That then covers
us for the case where a property is a union of DFDL String Literal and
DFDL Expression, as the rules for expression say it must return a value
compliant with the property type. So the only properties that need to take
your wording below are initiator, terminator and separator.
Is it a schema definition error or a processing error if an expression
evaluates to something that does not comply with the type of the property?
I don't think the spec says.
Regards
Steve Hanson
Architect, Data Format Description Language (DFDL)
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh at uk.ibm.com
tel:+44-1962-815848
From: Mike Beckerle <mbeckerle.dfdl at gmail.com>
To: Steve Hanson/UK/IBM at IBMGB
Cc: dfdl-wg at ogf.org
Date: 16/01/2012 22:17
Subject: Proposed Errata Language: Issue - DFDL Expressions may not
return empty string for ...
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
IBM SWG, Hursley, UK
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
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/20120117/7a33e00f/attachment-0001.html>
More information about the dfdl-wg
mailing list