clarification - lengthKind pattern IS allowed for hexBinary?

We have a restriction in Daffodil that doesn't allow lengthKind pattern for hexBinary, but I recently reviewed the spec and can find no such restriction. Did I miss the restriction somewhere else? I find no occurrences of 'pattern' nor 'hexbinary' in the current errata document. I would say it is inconsistent to disallow lengthKind pattern for hexBinary, after all, we allow lengthKind 'delimited' which scans the binary bits/bytes, and that means dfdl:encoding is needed for hexBinary when lengthKind is 'delimited', so we're already allowing the other things we would need to support lengthKind 'pattern' also. We do have a workaround which is to use a string with encoding iso-8859-1, but that just proves the point that really there is no reason why hexBinary doesn't allow this. 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>

Hi Mike Correct, there is no longer such a restriction, although IBM DFDL is in the same position as Daffodil. 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. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh@uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: "dfdl-wg@ogf.org" <dfdl-wg@ogf.org> Date: 31/10/2016 15:59 Subject: [DFDL-WG] clarification - lengthKind pattern IS allowed for hexBinary? Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org> We have a restriction in Daffodil that doesn't allow lengthKind pattern for hexBinary, but I recently reviewed the spec and can find no such restriction. Did I miss the restriction somewhere else? I find no occurrences of 'pattern' nor 'hexbinary' in the current errata document. I would say it is inconsistent to disallow lengthKind pattern for hexBinary, after all, we allow lengthKind 'delimited' which scans the binary bits/bytes, and that means dfdl:encoding is needed for hexBinary when lengthKind is 'delimited', so we're already allowing the other things we would need to support lengthKind 'pattern' also. We do have a workaround which is to use a string with encoding iso-8859-1, but that just proves the point that really there is no reason why hexBinary doesn't allow this. 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@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
participants (2)
-
Mike Beckerle
-
Steve Hanson