December 2012 - dfdl-wg - lists.ogf.org

3.13 on encoding errors - rewording - was Re: Second draft of DFDL Errata v011
by Mike Beckerle 16 Jan '13

16 Jan '13

*Re: Errata v11 3.13 I concluded that this needs a rewrite entirely, and that the policy we adopt has to allow for a reasonable implementation of scanning that doesn't require re-invention of the entire world of character I/O. I believe no changes are needed to section 4.1.2, so this errata is not about that section anymore, only about section 11. Suggested revised errata 3.13 text follows:* The encodingErrorPolicy property specified in Errata v10 is removed. A new sub-section is added to section 11. *(this is probably 11.2, if 11.1 is about Unicode byte order marks)* 11.2 Character Encoding and Decoding Errors When parsing, these are the errors that can occur when decoding characters into Unicode/ISO 10646. 1. The data is broken - invalid bit/byte sequences are found which do not match the definition of a character for the encoding. 2. Not enough data is found to make up the entire encoding of a character. That is, a fragment of a valid encoding is found. When unparsing, these are the errors that can occur when encoding characters from Unicode/ISO 10646 into the specified encoding. 1. No mapping provided by the encoding specification. 2. Not enough room to output the entire encoding of the character (e.g., need 3 bytes for a character encoding that uses 3-bytes for that character, but only 1 byte remains in the available length. The subsections below describe how these errors are handled. 11.2.1 Parsing: Decoding Errors When Scanning Scanning is searching of text for data matching: - a delimiter (this can be with or without an associated escape scheme) - initiators, terminators, and separators - a literal nil value (nilKind of 'literalValue' or 'literalCharacter') - a regular expression - for lengthKind='pattern' - for dfdl:assert or dfdl:discriminator with testKind='pattern' In all cases, if scanning encounters a decode error, then it stops with the the successfully decoded character immediately preceding the decode-error. This means that neither framing nor content that is scanned can ever encompass data that caused decode errors. It is worth specific note that the "." regular expression character which matches any character, does not allow a regular expression to subsume a decode error. It is also worth noting that the Unicode Replacement Character (U+FFFD) can appear in data as an ordinary character, but the scanning process will never create these from decode-errors. 11.2.2 Parsing: Decode Errors in Elements of Specified Length For elements with specified lengths (see glossary), the content region is processed and decode errors in conversion of this content region to text will result in the replacement of the non-decodable part of the data by one or more Unicode replacement characters (U+FFFD). If lengthUnits='characters', then such a Unicode replacement character counts as contributing a single character to the length. The trimming of padding characters happens after this replacement. 11.2.2.2 Parsing: The Not-Enough-Data Decode Error There is one special case for the 'not enough data' decode error. For lengthUnits='bytes' when the encoding is a fixed-width character set (see section 12.3.7.1.1 Character Width). If the number of bytes is not a multiple of the character set width, then there will be some number of bytes left over at the end of the data which are insufficient to hold an entire character code. In this case no attempt is made to decode a character from these left-over bytes. They are skipped when parsing (and filled with the dfdl:fillByte on unparsing). 11.2.3 Parsing: Unicode Decoding Non-Errors The following specific situations involving UTF-16, UTF-16LE, and UTF-16BE and do not cause a decoding or encoding error. • UTF-16 and unpaired surrogate code-point • UTF-16 and out-of-order surrogate code-point pair • UTF-16 encoding utf16Width='fixed' and a surrogate code point is encountered • UTF-16 byte-order-marks found not at the beginning of the data In all these cases the code-point becomes a character code in the DFDL Information Item for the string. 11.2.4 Unparsing: Substitution Character For unparsing, each encoding has a replacement/substitution character specified by the ICU. This character is substituted for the unmapped character or the character that has too large an encoding. The definitions of these substitution characters can be conveniently found for many encodings in the ICU Converter Explorer ( http://demo.icu-project.org/icu-bin/convexp) An encoding error is a processing error if the encoding does not provide a substitution/replacement character definition. (This would be rare, but could occur if a DFDL implementation allows many encodings beyond the minimum set.) 11.2.4.1 Unparsing: The Not-Enough-Room Encoding Error There is one special case for the 'not enough room' encoding error. For lengthUnits='bytes' when the encoding is a fixed-width character set (see section 12.3.7.1.1 Character Width). If the number of bytes is not a multiple of the character set width, then there will be some number of bytes of space left over at the end of the data which are insufficient to hold an entire character code. In this case no attempt is made to encode a character into these left-over bytes. They are filled with the dfdl:fillByte. (On parsing they are skipped.) 11.2.5 Preserving Data Containing Decoding Errors There can be situations where data wants to be preserved exactly even if it contains errors. It is suggested that if a DFDL schema author wants to preserve information containing data where the data may have decoding of errors, that they model such data as xs:hexBinary, or as xs:string but using an encoding such as iso-8859-1 which preserves all bytes.

1 2

Action 191 - Clarify what constitutes Schema Definition vs. Processing Error
by Mike Beckerle 15 Jan '13

15 Jan '13

Attached is a document about Action 191 which is a list of specfic errors. -- Mike Beckerle | OGF DFDL WG Co-Chair | Tresys Technologies Tel: 781-330-0412

1 2

irrelevant properties
by Mike Beckerle 03 Jan '13

03 Jan '13

It's hard to search for this. Does anyone recall resolution to this? If you specify properties that are clearly mismatched e.g., you specify dfdl:occursCountKind on an element that isn't an array, or you specify dfdl:textStringJustification on a number. Does this generate an error or a warning or nothing? Obviously this doesn't cause any issue if these properties are in scope or referenced from a format annotation. It's only an issue if they are actually written locally in short or long-form annotations right on the point where the incompatibility resides. -- Mike Beckerle | OGF DFDL WG Co-Chair | Tresys Technologies Tel: 781-330-0412

2 1

Errata v011 draft updated in Redmine
by Steve Hanson 14 Dec '12

14 Dec '12

Some corrections have been made, plus three errata have been flagged as being under review by the WG. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 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

1 0

Cancelled: OGF DFDL Working Group weekly call
by Steve Hanson 14 Dec '12

14 Dec '12

Next call is Tues 8th Jan

1 0

spec bug Section 14.5 Hidden Groups
by Mike Beckerle 13 Dec '12

13 Dec '12

The example in section 14.5 does not have proper DFDL schema syntax (no annotation/appinfo surrounding the dfdl:sequence element.). -- Mike Beckerle | OGF DFDL WG Co-Chair | Tresys Technologies Tel: 781-330-0412

2 1

Re: [DFDL-WG] Proposed Errata: New function dfdl:stringLiteralToString
by Steve Hanson 12 Dec '12

12 Dec '12

Should name be dfdl:stringFromStringLiteral to mirror existing dfdl:stringLiteralFromString (or should the latter be dfdl:stringToStringLiteral - follows the Java toString() pattern) ? Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com>, Cc: dfdl-wg(a)ogf.org, dfdl-wg-bounces(a)ogf.org Date: 12/12/2012 17:20 Subject: Re: [DFDL-WG] Proposed Errata: New function dfdl:stringLiteralToString Mike, should we disallow DFDL Character Class entities also ? Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: dfdl-wg(a)ogf.org, Date: 12/12/2012 15:40 Subject: [DFDL-WG] Proposed Errata: New function dfdl:stringLiteralToString Sent by: dfdl-wg-bounces(a)ogf.org Proposed Errata: The following function is provided to assist in creating data that contains characters expressed using DFDL String Literal syntax. dfdl:stringLiteralToString($arg) Returns a string constructed from the $arg string argument. If $arg contains syntax matching DFDL Character Entites syntax, then the corresponding characters are used in the result. Any characters in $arg not matching the DFDL Character Entities syntax remain unchanged in the result. Note that DFDL Byte Value Entities are not allowed. It is a schema definition error if $arg contains syntax matching DFDL Byte Value Entities syntax. Use this function when you need to create a value which contains characters for which DFDL Character Entities are needed. An example is to create data containing the NUL (character code 0) codepoint. This character code is not allowed in XML documents, including DFDL Schemas; hence, it must be specified using a DFDL Character Entity. Within a DFDL Expression, use this function to obtain a string containing this character. Example: dfdl:outputValueCalc='{ fn:concat(../x, dfdl:stringLiteralToString("%NUL;")) }' -- Mike Beckerle | OGF DFDL WG Co-Chair | Tresys Technologies Tel: 781-330-0412 -- dfdl-wg mailing list dfdl-wg(a)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 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

2 1

OGF DFDL WG Call Minutes 2012-12-11
by Steve Hanson 12 Dec '12

12 Dec '12

Please find minutes from the above call on Redmine at http://redmine.ogf.org/dmsf_files/12977?download= Errata document is now at v011 (draft) here: http://redmine.ogf.org/dmsf_files/8104?download= Regards Steve Hanson Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Proposed Errata: New function dfdl:stringLiteralToString
by Mike Beckerle 12 Dec '12

12 Dec '12

Proposed Errata: The following function is provided to assist in creating data that contains characters expressed using DFDL String Literal syntax. dfdl:stringLiteralToString($arg) Returns a string constructed from the $arg string argument. If $arg contains syntax matching DFDL Character Entites syntax, then the corresponding characters are used in the result. Any characters in $arg not matching the DFDL Character Entities syntax remain unchanged in the result. Note that DFDL Byte Value Entities are not allowed. It is a schema definition error if $arg contains syntax matching DFDL Byte Value Entities syntax. Use this function when you need to create a value which contains characters for which DFDL Character Entities are needed. An example is to create data containing the NUL (character code 0) codepoint. This character code is not allowed in XML documents, including DFDL Schemas; hence, it must be specified using a DFDL Character Entity. Within a DFDL Expression, use this function to obtain a string containing this character. Example: dfdl:outputValueCalc='{ fn:concat(../x, dfdl:stringLiteralToString("%NUL;")) }' -- Mike Beckerle | OGF DFDL WG Co-Chair | Tresys Technologies Tel: 781-330-0412

2 2

clarification needed: choice children have separator from surrounding sequence or not?
by Mike Beckerle 12 Dec '12

12 Dec '12

Consider this textual delimited DFDL schema fragment: <sequence dfdl:separator="/" dfdl:separatorPosition="prefix"> <element name="a" type="xs:string"/> <choice dfdl:initiator="(" dfdl:terminator=")"> <element name="foo" maxOcccurs="10" type="xs:int" dfdl:occursCountKind="parsed" dfdl:terminator=";"/> <element name="bar" type="xs:string" /> </choice> </sequence> Is the separator of the enclosing sequence expected to appear before 'foo' and 'bar' elements inside the choice? If you consider this data '/abc/(/1;/2;/3;/4;)' versus this data '/abc/(1;2;3;4;)' We have to have the / after the abc to find the end of element 'a'. The choice's initiator won't be used as terminating markup. However, then when we have instances of the children of the choice like 'foo' elements, do those have the prefix separator / inherited from the surrounding sequence outside the choice, or do they behave as if surrounded by an inner implied sequence which has no separator? I'm convincing myself that the latter must be the interpretation, but I wanted to see what others think. ...mikeb -- Mike Beckerle | OGF DFDL WG Co-Chair | Tresys Technologies Tel: 781-330-0412

2 1