- dfdl-wg - lists.ogf.org

Action 292 - Write up of hexBinary with lengthUnits 'bits'
by Mike Beckerle 20 Nov '18

20 Nov '18

The proposed change is to allow lengthUnits 'bits' for hexBinary data. This turned out to be more complex to describe than I originally suspected because of the need to deal with XSD minLength and maxLength facets, which are always measured in bytes. Those in conjunction with dfdl:lengthKind='explicit' and dfdl:lengthUnits='bits' create some minor complexities. The below changes match the Daffodil implementation of this proposed feature. These sentences in the description of dfdl:lengthUnits in Section 12.3 must change. - 'bits' may only be used for xs:boolean, xs:byte, xs:short, xs:int, xs:long, xs:unsignedByte, xs:unsignedShort, xs:unsignedInt, and xs:unsignedLong simple types with binary representation. - 'bytes' must be used for type xs:hexBinary. The text should read - 'bits' may only be used for xs:hexBinary and for xs:boolean, xs:byte, xs:short, xs:int, xs:long, xs:unsignedByte, xs:unsignedShort, xs:unsignedInt, and xs:unsignedLong simple types with binary representation. Later in the section, the paragraph: When unparsing a simple element with binary representation, then for hexBinary the length is the number of bytes in the infoset value padded to the XSD minLength facet value using dfdl:fillByte, and for the other types the length is the minimum number of bytes to represent the value and any sign. Must change to: When unparsing a simple element with binary representation, then for types other than hexBinary the length is the minimum number of bytes to represent the value and any sign. For type hexBinary when the dfdl:lengthUnits is 'bytes' then the length is the number of bytes in the infoset value padded to the XSD minLength facet value using dfdl:fillByte. For type hexBinary when the dfdl:lengthUnits is 'bits': - First the data is padded to XSD minLength bytes as if the dfdl:lengthUnits was 'bytes'. - When dfdl:lengthKind is other than 'explicit', the length is the number of bytes times 8. - When the dfdl:lengthKind is 'explicit' then the value is further padded or truncated to fit the target length, in bits. - if the data does not have sufficient bytes to supply the target length in bits it is a processing error. - if the data is longer than the minimum number of bytes needed to supply the target length in bits, it is a processing error. - If the explicit length in bits is not a multiple of 8, then the final byte is only partially unparsed according to the current dfdl:byteOrder. Section 12.3.7.2.7 Length of Binary Opaque Elements, the first sentence must be modified from: "The dfdl:lengthUnits property must be 'bytes'. It is a schema definition error otherwise." to "The dfdl:lengthUnits property must be 'bytes' or 'bits'. It is a schema definition error otherwise. Note that even when the dfdl:lengthUnits property is 'bits', the values of the XSD minLength and XSD maxLength facets are still always interpreted as constraining the length in units of bytes. That's the end of the actual proposed language. Note about alternatives: I considered the alternative to make it a schema definition error when dfdl:lengthUnits is 'bits' type is 'xs:hexBinary', and the XSD:minLength or XSD:maxLength facets are defined. I decided to go with the description above to support the use case where a data item is, in hex, some number of bytes long for a valid XML infoset, but the representation is explicitly a partial byte smaller. E.g., in a hexBinary with 8 bytes, but fewer than 64 bits in the representation. Ex: 63 bits as the explicit target length, so 1 bit will be unused from the xs:hexBinary logical value, but the above rules insure no more than 7 bits go unused from the final byte of the hexBinary logical value. This is trying to be consistent with the notion that we do not truncate data to fit into the available length except for xs:string when properties explicitly allow it. It is also trying to be consistent with our treatment of binary integers where a xs:long value may be output into an element having room for any number of bits, and any extra bits in the logical value are ignored. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>

2 2

Latest OGF DFDL WG Call Minutes
by Steve Hanson 15 Nov '18

15 Nov '18

Please find minutes from the latest call at https://redmine.ogf.org/projects/dfdl-wg/news Regards Steve Hanson IBM Hybrid Integration Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

Agenda for today's OGF DFDL WG Call
by Steve Hanson 15 Nov '18

15 Nov '18

Please find agenda for call on Redmine at https://redmine.ogf.org/dmsf_files/13582?download= Regards Steve Hanson IBM Hybrid Integration Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

Fw: Suggest should be optional feature of DFDL - dfdl:utf16Width='variable' and other corner cases (action 290)
by Steve Hanson 15 Nov '18

15 Nov '18

Hi Mike I've been looking into IBM DFDL's treatment of property dfdl:utf16Width. While we claim to support 'variable' and have a few tests that use this, there is not the number of tests that I would expect to test the property fully. The intent to support 'variable' is clear in the code, though; for example, when parsing we check each char for being part of a surrogate pair and adjust length accordingly. The code uses java.nio.charset for its encoders & decoders, which we wrap in our own class which notes whether utf16 is fixed or variable, but this information is not passed to the encoder/decoder as there is no way to do so. Hmm. We will add some more tests and see if everything is behaving. Back to your original question, should 'variable' be an optional feature of the spec. I have discussed with implementation team members and we think that is a sensible thing to do. To handle surrogates does require extra code to be written, and for a minimal implementation it should not be necessary to do that. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 Note: I work Tuesday to Friday From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org> Date: 04/04/2017 11:56 Subject: Re: [DFDL-WG] Suggest should be optional feature of DFDL - dfdl:utf16Width='variable' and other corner cases Some light on action 291 - see the last sentence of this extract from the original errata document (experience doc 1): 3.9. Section 12.3.5, 7.3.1, 7.3.2. The spec originally allows lengthKind ‘pattern’ to be used when the representation of the current element, or of a child element, is binary, but imposes restrictions on the encoding that can be in force. Clarify that the encoding property must be defined for the element (else schema definition error), and that a decoding processing error is possible if the match of the regex encounters data that does not decode in that encoding, dependent on the setting of encodingErrorPolicy. Remove section 12.3.5.1. Same clarifications needed for testKind ”pattern” property for asserts and discriminators. For consistency, the restriction that a complex element of specified length and lengthUnits ‘characters’ must have children that are all text and that have the same encoding as the complex element, is dropped So that explains how IBM DFDL's error message CTDV1524E came about, it was policing a restriction in the original GFD.174 spec, a restriction which no longer exists. IBM DFDL has not yet implemented the erratum. It wasn't an extra IBM restriction. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org> Date: 14/09/2016 08:44 Subject: Re: [DFDL-WG] Suggest should be optional feature of DFDL - dfdl:utf16Width='variable' and other corner cases Actions 290 and 291 raised to investigate further - see minutes. Regards Steve Hanson IBM Integration Bus, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org> Date: 13/09/2016 13:14 Subject: Re: [DFDL-WG] Suggest should be optional feature of DFDL - dfdl:utf16Width='variable' and other corner cases Mike I am assuming that the processing for utf-16 'fixed' or 'variable' is entirely handled by ICU so there should be no coding overhead. IBM DFDL works ok for dfdl:lengthKind='explicit' for an element of complex type with dfdl:lengthUnits='characters' and dfdl:encoding="utf-8". But there are conditions the content of the complex type must satisfy otherwise an SDE results, such as: CTDV1524E : For a complex element, when 'lengthKind' is 'explicit' or 'prefixed', and 'lengthUnits' is characters, all simple child elements must have text representation, 'lengthUnits' set to 'characters' and the same encoding. So we insist that the properties of the children are consistent with the properties of the parent. If you recall, IBM DFDL does all these kinds of validation checks in a pre-processing phase. That seems a pretty sensible rule but I am not sure if the rule appears in the spec as such - I just had a quick look but didn't spot anything. So I guess I don't see a need for these things to be optional features? Regards Steve Hanson IBM Integration Bus, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org> Date: 10/08/2016 18:57 Subject: [DFDL-WG] Suggest should be optional feature of DFDL - dfdl:utf16Width='variable' and other corner cases Sent by: "dfdl-wg" <dfdl-wg-bounces(a)ogf.org> Given the limited set of required encodings for a conforming DFDL processor, I believe dfdl:utf16Width='variable' should be an optional feature. That's just consistency with what is optional already. But it is also quite hard to implement. There are other situations that are very hard to implement, probably never used by real users, yet which are non optional in the spec: I would suggest that dfdl:lengthKind='explicit' for elements of complex type, with dfdl:lengthUnits='characters' and a variable-width encoding like utf-8 is very problematic to implement. I am pretty sure IBM DFDL has no implementation of this per email threads, and I know I don't want to implement this in Daffodil even though we're trying to be very comprehensive in the implementation eventually. I think implementations should be free to just not implement this. These sorts of cases often exist just because we're trying to preserve some orthogonality of composition in the language. So it's possible to do quite a few things that probably aren't ever needed by anyone, that reflect ill-defined data formats, etc. I'd rather not document a bunch of "non-conformances" for Daffodil or other implementations for these sorts of things. I'd like to say we don't implement them, but they're optional, and so that's allowed. Comments? Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy -- 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 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

1 0

Latest OGF DFDL WG Call Minutes
by Steve Hanson 01 Nov '18

01 Nov '18

Please find minutes from the latest call at https://redmine.ogf.org/projects/dfdl-wg/news Regards Steve Hanson IBM Hybrid Integration Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

Agenda for today's OGF DFDL WG Call
by Steve Hanson 01 Nov '18

01 Nov '18

Please find agenda for call on Redmine at https://redmine.ogf.org/dmsf_files/13581?download= Regards Steve Hanson IBM Hybrid Integration Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

Rescheduled: OGF DFDL Working Group Call (1 Nov 15:00 GMT)
by Steve Hanson 25 Oct '18

25 Oct '18

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

OGF DFDL Working Group Call
by Steve Hanson 25 Oct '18

25 Oct '18

1 0

OGF DFDL Working Group Call
by Steve Hanson 25 Oct '18

25 Oct '18

1 0

OGF DFDL Working Group Call
by Steve Hanson 25 Oct '18

25 Oct '18

1 0