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

On 3 July 2013 19:57, Florent Georges wrote:
> On 3 July 2013 19:39, Michael Kay wrote:

>>>  I like that approach.  Actually why don't we provide such
>>> "converter functions" from both xs:hexBinary and xs:base64Binary
>>> (plus their lexical representation) to an implementation-dependent
>>> type, which can be used only as input parameters (or as return
>>> value) of the binary module functions?

>> I think there's a considerable risk that a user who gets a base64
>> value (say) from somewhere would pass it to a method that accepts
>> hexB on one implementation and b64B on another, forgetting to
>> invoke the conversion, and thus producing non-portable code.

>   Sorry, I don't understand this one.  Could you expand a little bit
> on it, please?

  Mmh, I think I might understand where the confusion is.  I did not
mean that the choice between xs:hexBinary and xs:base64Binary would be
implementation-defined, but rather to define a new item type (probably
under xs:anyAtomicType or under item()), defined to be different from
any other existing type.  And so if a user passes directly a hex or
base64 binary directly to a bin:* function, that would raise an error
(on all implementations).

  One implementation could have bin:from-base64(), bin:to-base64(),
bin:from-hex(), and bin:to-hex() defined as almost no-ops if possible,
or could favour base64 over hex for instance, but from a user point of
view, they'll always have to pass through this new binary item type.

  I think the main advantage, behind having a clear spec, is to ease
writing a general-purpose library involving binaries (well, any set of
function handling binaries, really).  For instance a library to manage
tags in pictures.  The library functions will take pictures in and out
as binaries:

    png:get-tag($pic as bin:binary,
                $name as xs:string) as xs:string

    png:set-tag($pic as bin:binary,
                $name as xs:string,
                $value as xs:string) as bin:binary

  If the Binary module does not define one "standard" item type for
binaries, all APIs will have to be duplicated (or worse, to use only
one of hex or base64).  And internally there is a great chance that
one will be favoured over the other.

  But if the Binary module does define that "standard", abstract item
type for binaries, then it provides the user (and the implementers)
with the right level of abstraction, and those concerns about how it
is implemented stay in the implementation.

  Regards,

-- 
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/

Received on Thursday, 4 July 2013 08:30:35 UTC