[DFDL-WG] new language for 2.3.1 of draft 038

[Mike Beckerle]

Below is new language for section 2.3.1.

I decided that the issue here is about ambiguity in general, and not just
lengthKind="delimited".

I also can't think of any other situation like this one besides ambiguity.
Are there others?


...mikeb


2.3.1 Ambiguity of Data Formats

A data format description using dfdl:lengthKind="delimited" may be ambiguous
if the delimiters are not distinct, and a data format description which has
fixed data requirements (some elements having required fixed values), may be
ambiguous regardless of the dfdl:lengthKind setting.[1] <#_ftn1>

Note that if the delimiter string values are stored within the data, perhaps
as elements of a header part of the data, then this ambiguity certainly
cannot be examined until the data is available.

Given an ambiguous grammar, a DFDL implementation may successfully parse a
particular input data stream. That is, the part of the schema with the
ambiguity may not be exercised by a particular data stream, or the data may
parse successfully anyway; that is, the ambiguity may not cause any kind of
failure or processing error.

Hence, to insure compatible behavior, DFDL v1.0 implementations MUST not
detect grammar ambiguities as errors. Implementations are of course free to
issue warnings to help users identify these situations, but ambiguity is
neither a Schema Definition Error, nor a Processing Error.

------------------------------

[1] <#_ftnref1> A very complex analysis is required to identify this sort of
grammar ambiguity in general. While we believe this may be decidable for
DFDL v1.0, future versions of DFDL may add features (such as recursive
types) which make this analysis undecidable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20100207/0b3afa63/attachment.html