proposed dfdl:hexBinary function for hex constants in schemas
Separated out from prior proposal where it was mixed in with another topic. dfdl:hexBinary($arg as xs:anyAtomicType?) as xs:hexBinary? This function provides an extension to the behavior of the xs:hexBinary constructor. The argument can be a string, in which case the behavior is as the xs:hexBinary constructor. The argument can also be a long, unsignedLong, or any subtype thereof, and in that case a string containing hexadecimal digits is produced. The hexadecimal digits produced that are letters are always uppercase. The number of hex digits in the resulting string is a function of the input type. If byte or unsigned byte, exactly 2 hex digits are produced, for short and unsignedShort, 4 hex digits, and so on. The hex digits correspond to a big-endian representation of a twos-complement binary representation of the argument value. So: dfdl:short(xs:concat('x', dfdl:hexBinary(xs:short(208)))) eq xs:short(208) is true, and a corresponding tautology holds for all the other DFDL functions that construct integers from hexadecimal, if you replace the 208 above with a value in range for the corresponding numeric type. If the argument is a numeric literal, then the smallest signed integer type (long, int, short, byte) is selected that can contain the value, and the number of hexadecimal digits produced corresponds to that type. So: dfdl:hexBinary(208) eq 'D0' dfdl:hexBinary(-2084) eq 'F7FF' -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com
This proposal is phrased as if xs:hexBinary was a string constructor. That's not the case, the result type is xs:hexBinary. Here is the rephrased proposal: dfdl:hexBinary($arg as xs:anyAtomicType?) as xs:hexBinary? This function provides an extension to the behavior of the xs:hexBinary constructor. The argument can be a string, in which case the behavior is as the xs:hexBinary constructor. The argument can also be a long, unsignedLong, or any subtype thereof, and in that case a xs:hexBinary value containing a number of bytes is produced. The ordering of the bytes and number of bytes corresponds to a binary big-endian twos-complement implementation of the type of the argument. Hence, an argument of primitive type xs:unsignedLong would produce an xs:hexBinary value containing 8 bytes, and an argument of primitive type xs:short will produce an xs:hexBinary value containing 2 bytes. So: dfdl:short(xs:concat('x', xs:string(dfdl:hexBinary(xs:short(208))))) eq xs:short(208) is true, and a corresponding tautology holds for all the other DFDL functions that construct integers from hexadecimal, if you replace the 208 above with a value in range for the corresponding numeric type. If the argument is a numeric literal, then the smallest signed integer type (long, int, short, byte) is selected that can contain the value, and the number of hexadecimal digits produced corresponds to that type. So: dfdl:hexBinary(208) produces a hexBinary value containing 1 byte, which converted to a string will be either "D0" or "d0". dfdl:hexBinary(-2084) produces a hexBinary value containing 2 bytes, which converted to a string will be either "F7FF" or "f7ff". On Tue, Jul 16, 2013 at 10:43 AM, Mike Beckerle <mbeckerle.dfdl@gmail.com>wrote:
Separated out from prior proposal where it was mixed in with another topic.
dfdl:hexBinary($arg as xs:anyAtomicType?) as xs:hexBinary?
This function provides an extension to the behavior of the xs:hexBinary constructor. The argument can be a string, in which case the behavior is as the xs:hexBinary constructor. The argument can also be a long, unsignedLong, or any subtype thereof, and in that case a string containing hexadecimal digits is produced. The hexadecimal digits produced that are letters are always uppercase. The number of hex digits in the resulting string is a function of the input type. If byte or unsigned byte, exactly 2 hex digits are produced, for short and unsignedShort, 4 hex digits, and so on. The hex digits correspond to a big-endian representation of a twos-complement binary representation of the argument value. So:
dfdl:short(xs:concat('x', dfdl:hexBinary(xs:short(208)))) eq xs:short(208)
is true, and a corresponding tautology holds for all the other DFDL functions that construct integers from hexadecimal, if you replace the 208 above with a value in range for the corresponding numeric type.
If the argument is a numeric literal, then the smallest signed integer type (long, int, short, byte) is selected that can contain the value, and the number of hexadecimal digits produced corresponds to that type. So:
dfdl:hexBinary(208) eq 'D0' dfdl:hexBinary(-2084) eq 'F7FF'
-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com
-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com
I think we should choose one of A-F or a-f as the nibbles, rather than leave it implementation dependent ? Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 16/07/2013 16:42 Subject: Re: [DFDL-WG] proposed dfdl:hexBinary function for hex constants in schemas Sent by: dfdl-wg-bounces@ogf.org This proposal is phrased as if xs:hexBinary was a string constructor. That's not the case, the result type is xs:hexBinary. Here is the rephrased proposal: dfdl:hexBinary($arg as xs:anyAtomicType?) as xs:hexBinary? This function provides an extension to the behavior of the xs:hexBinary constructor. The argument can be a string, in which case the behavior is as the xs:hexBinary constructor. The argument can also be a long, unsignedLong, or any subtype thereof, and in that case a xs:hexBinary value containing a number of bytes is produced. The ordering of the bytes and number of bytes corresponds to a binary big-endian twos-complement implementation of the type of the argument. Hence, an argument of primitive type xs:unsignedLong would produce an xs:hexBinary value containing 8 bytes, and an argument of primitive type xs:short will produce an xs:hexBinary value containing 2 bytes. So: dfdl:short(xs:concat('x', xs:string(dfdl:hexBinary(xs:short(208))))) eq xs:short(208) is true, and a corresponding tautology holds for all the other DFDL functions that construct integers from hexadecimal, if you replace the 208 above with a value in range for the corresponding numeric type. If the argument is a numeric literal, then the smallest signed integer type (long, int, short, byte) is selected that can contain the value, and the number of hexadecimal digits produced corresponds to that type. So: dfdl:hexBinary(208) produces a hexBinary value containing 1 byte, which converted to a string will be either "D0" or "d0". dfdl:hexBinary(-2084) produces a hexBinary value containing 2 bytes, which converted to a string will be either "F7FF" or "f7ff". On Tue, Jul 16, 2013 at 10:43 AM, Mike Beckerle <mbeckerle.dfdl@gmail.com> wrote: Separated out from prior proposal where it was mixed in with another topic. dfdl:hexBinary($arg as xs:anyAtomicType?) as xs:hexBinary? This function provides an extension to the behavior of the xs:hexBinary constructor. The argument can be a string, in which case the behavior is as the xs:hexBinary constructor. The argument can also be a long, unsignedLong, or any subtype thereof, and in that case a string containing hexadecimal digits is produced. The hexadecimal digits produced that are letters are always uppercase. The number of hex digits in the resulting string is a function of the input type. If byte or unsigned byte, exactly 2 hex digits are produced, for short and unsignedShort, 4 hex digits, and so on. The hex digits correspond to a big-endian representation of a twos-complement binary representation of the argument value. So: dfdl:short(xs:concat('x', dfdl:hexBinary(xs:short(208)))) eq xs:short(208) is true, and a corresponding tautology holds for all the other DFDL functions that construct integers from hexadecimal, if you replace the 208 above with a value in range for the corresponding numeric type. If the argument is a numeric literal, then the smallest signed integer type (long, int, short, byte) is selected that can contain the value, and the number of hexadecimal digits produced corresponds to that type. So: dfdl:hexBinary(208) eq 'D0' dfdl:hexBinary(-2084) eq 'F7FF' -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- 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
How about this: - The constructors dfdl:byte(), dfdl:short() etc accept either lower or upper case. The hexBinary function outputs the canonical hexBinary form, which is uppercase. regards, Tim Kimber, DFDL Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Steve Hanson/UK/IBM@IBMGB To: Mike Beckerle <mbeckerle.dfdl@gmail.com>, Cc: dfdl-wg@ogf.org, dfdl-wg-bounces@ogf.org Date: 19/07/2013 17:30 Subject: Re: [DFDL-WG] proposed dfdl:hexBinary function for hex constants in schemas Sent by: dfdl-wg-bounces@ogf.org I think we should choose one of A-F or a-f as the nibbles, rather than leave it implementation dependent ? Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 16/07/2013 16:42 Subject: Re: [DFDL-WG] proposed dfdl:hexBinary function for hex constants in schemas Sent by: dfdl-wg-bounces@ogf.org This proposal is phrased as if xs:hexBinary was a string constructor. That's not the case, the result type is xs:hexBinary. Here is the rephrased proposal: dfdl:hexBinary($arg as xs:anyAtomicType?) as xs:hexBinary? This function provides an extension to the behavior of the xs:hexBinary constructor. The argument can be a string, in which case the behavior is as the xs:hexBinary constructor. The argument can also be a long, unsignedLong, or any subtype thereof, and in that case a xs:hexBinary value containing a number of bytes is produced. The ordering of the bytes and number of bytes corresponds to a binary big-endian twos-complement implementation of the type of the argument. Hence, an argument of primitive type xs:unsignedLong would produce an xs:hexBinary value containing 8 bytes, and an argument of primitive type xs:short will produce an xs:hexBinary value containing 2 bytes. So: dfdl:short(xs:concat('x', xs:string(dfdl:hexBinary(xs:short(208))))) eq xs:short(208) is true, and a corresponding tautology holds for all the other DFDL functions that construct integers from hexadecimal, if you replace the 208 above with a value in range for the corresponding numeric type. If the argument is a numeric literal, then the smallest signed integer type (long, int, short, byte) is selected that can contain the value, and the number of hexadecimal digits produced corresponds to that type. So: dfdl:hexBinary(208) produces a hexBinary value containing 1 byte, which converted to a string will be either "D0" or "d0". dfdl:hexBinary(-2084) produces a hexBinary value containing 2 bytes, which converted to a string will be either "F7FF" or "f7ff". On Tue, Jul 16, 2013 at 10:43 AM, Mike Beckerle <mbeckerle.dfdl@gmail.com> wrote: Separated out from prior proposal where it was mixed in with another topic. dfdl:hexBinary($arg as xs:anyAtomicType?) as xs:hexBinary? This function provides an extension to the behavior of the xs:hexBinary constructor. The argument can be a string, in which case the behavior is as the xs:hexBinary constructor. The argument can also be a long, unsignedLong, or any subtype thereof, and in that case a string containing hexadecimal digits is produced. The hexadecimal digits produced that are letters are always uppercase. The number of hex digits in the resulting string is a function of the input type. If byte or unsigned byte, exactly 2 hex digits are produced, for short and unsignedShort, 4 hex digits, and so on. The hex digits correspond to a big-endian representation of a twos-complement binary representation of the argument value. So: dfdl:short(xs:concat('x', dfdl:hexBinary(xs:short(208)))) eq xs:short(208) is true, and a corresponding tautology holds for all the other DFDL functions that construct integers from hexadecimal, if you replace the 208 above with a value in range for the corresponding numeric type. If the argument is a numeric literal, then the smallest signed integer type (long, int, short, byte) is selected that can contain the value, and the number of hexadecimal digits produced corresponds to that type. So: dfdl:hexBinary(208) eq 'D0' dfdl:hexBinary(-2084) eq 'F7FF' -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- 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 -- 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 (3)
-
Mike Beckerle -
Steve Hanson -
Tim Kimber