Re: xs:hexBinary or base64binary (Was: Re: Comments on binary specification)

On 14/03/2013 08:58, Christian Grün wrote:
>> I agree that for input parameters functions should accept both
>> xs:hexBinary and xs:base64Binary. However I'm not sure how to make this
>> work for EXPath which probably targets just XPath 2.0, not XPath 3.0. In
>> XPath 2.0 there is no support for union types. And function signatures
>> must have different arity, different types are not sufficient for
>> differentiation between function definitions (if I understand rules
>> correctly).
> …a quick question to Michael, and maybe others: would it still be an
> option to include a xs:binary type in future versions of the XDM, or
> has this already been discussed and rejected years ago?
>
I've campaigned hard to get full support for union types into XPath 3.0, 
and we're largely there, except that we don't have syntax for declaring 
a union type locally in a function signature. I'd like to be able to do

declare f ($x as union(xs:hexBinary, xs:base64Binary))

which would mean that the union type doesn't need to be recognized in 
XDM for it to be usable.

Inserting an abstract parent type into the type hierarchy is much more 
difficult. We did it with xs:anyAtomicType but it's surprisingly 
disruptive, for example an application that uses the Xerces schema API 
may stop working.

We could define our functions in terms of a type alias bin:binary and 
suggest a number of possible implementations:

(a) the function might be implemented to accept xs:anyAtomicType and 
raise a type error if the supplied value is not hexBinary or base64Binary

(b) bin:binary might be implemented as a built-in union type

(c) bin:binary might be implemented as a built-in abstract supertype for 
hexBinary and base64Binary.

Whichever of these is chosen, it should be clear that (like "numeric" in 
the F+O functions) it's not (necessarily) a real type that users can use 
in their own functions.

Received on Thursday, 14 March 2013 09:50:48 UTC