Re: Comment on "Allow both xs:base64Binary and xs:hexBinary as arguments"

For the return type, we have to choose one, and I would suggest going with base64Binary as that's what the file module uses. Note that it makes no difference unless someone converts the value to a string.

For argument types, there are two problems with accepting both: 

(a) the specification difficulties (which we can get around), and 

(b) the problem of what happens if the user supplies an untypedAtomic value (or an untyped node). The lexical spaces of hexBinary and base64Binary aren't disjoint (I believe) so this would be ambiguous. I think this makes it unacceptable.

So I think we should accept base64Binary throughout, and rely on users to convert. As regards the usability of hex literals, let's provide a function

bin:hex("CAFEBABE")

which accepts a string in the lexical space of hexBinary and returns a base64Binary value that can be used as input to the functions.

Michael Kay
Saxonica


On 3 Jul 2013, at 16:27, Florent Georges wrote:

>  Hi Jirka,
> 
>  On https://github.com/fgeorges/expath-cg/issues/9, you've just said:
> "Agreement seems to be allow both types and in signatures to use
> xs:anyAtomicType.  However spec will define that it would be error if
> other value then xs:base64Binary or xs:hexBinary is used."
> 
>  1/ This is usable for function parameters, not for return values.
>     What in that case?
> 
>  2/ Instead of mentioning xs:anyAtomicType, why not defining the spec
>     in term of a union type bin:binary instead (in the EXPath Binary
>     namespace), being the union of xs:hexBinary and xs:base64Binary?
>     Maybe with a note for implementations not supporting union types
>     that they have to accept both, and raise an error for any other
>     type.
> 
>  I think 1/ has been discussed, what would be your choice?  I don't
> think 2/ has been discussed before (at least I could not find so).
> 
>  Any idea?
> 
>  Regards,
> 
> -- 
> Florent Georges
> http://fgeorges.org/
> http://h2oconsulting.be/
>

Received on Wednesday, 3 July 2013 17:08:14 UTC