W3C home > Mailing lists > Public > public-expath@w3.org > March 2013

Re: An type for octets in the Binary Module

From: Michael Kay <mike@saxonica.com>
Date: Thu, 14 Mar 2013 13:21:04 +0000
Message-ID: <5141CEC0.6030703@saxonica.com>
To: public-expath@w3.org

On 14/03/2013 12:55, Florent Georges wrote:
>    Hi,
>    First, thank you Jirka for this great quality "first draft" of
> the Binary Module!
>    So if I understand correctly, binary-to-octets() returns
> xs:integers because xs:byte <http://w3.org/TR/xmlschema-2/#byte>
> is not supported by XQuery nor by XSLT/Basic.  Even though
> xs:byte would be perfect here has it has exactly the same value
> space as an octet.
I think it should be unsignedByte (0..255) rather than byte (-128..127).

I don't there's any reason to not use unsignedByte as the return type of 
binary-to-octets. There's no restriction on its use in XQuery. It's not 
directly supported by XSLT 2.0 Basic, but that's not a problem - there 
are functions like fn:prefix-from-QName that return xs:NCName, which 
isn't in XSLT 2.0 Basic either, but you simply treat it as the next 
supertype which is supported, e.g. xs:integer.

For arguments, we generally avoid restricted types because it's such a 
pain to have to cast things to the relevant type. So for 
octets-to-binary, the argument should be xs:integer*, allowing you to do 

Note that for string-to-codepoints the return type is declared as 
xs:integer* although it could have been constrained to xs:unsignedInt*

Note also that if the return type is declared as xs:integer* that 
doesn't stop an implementation returning xs:unsignedByte* if that's more 
efficient - an implementation can always return a subtype of the 
declared type.

So I would stick with xs:integer*.
>    Would it be possible to define a new type, say bin:octet, which
> derives from xs:decimal or xs:integer, with the same facets as
> xs:byte, and to use it in the signature of the functions?
Seems a quite unnecessary complication.

Michael Kay
Received on Thursday, 14 March 2013 13:21:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:37 UTC