new language for 2.3.1 of draft 038

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.
participants (1)
-
Mike Beckerle