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

On 13.3.2013 11:01, Michael Kay wrote:

> 4.1 bin:unparsed-binary, rules para 1 "string representation" ->
> "binary representation".
> 
> This function seems to duplicate file:read-binary() in the File
> module. Let's reuse that instead. Also, since the file module has
> chosen base64binary rather than hexBinary as its binary data type,
> let's use that (it's unlikely to affect the implementation, since the
> value space of both types is the same and conversion is probably a
> no-op except for the type label).

I agree that consistent type should be used. I used xs:hexBinary as we
agreed on it during XSLT WG meeting in Prague and in fact I haven't
consulted other EXPath modules (my bad) and thus haven't noticed that
bin:unparsed-binary is redundant.

Speaking of choice between hexBinary/base64Binary I have only one
concern. Lexical representation of hexBinary is easy to read even if you
don't have base64-decoder in your brain. This could be very convenient
if you see debug messages containing binary data.
Also if we will use base64Binary as a default it will be very
inconvenient to write some binary constant directly in code. For example
testing of magic cookie of PDF will became

bin:binary-subsequence($data, 0, 4) eq
xs:base64Binary(xs:hexBinary("25504446"))

(Note nested call of xs:base64Binary(xs:hexBinary()))

As it seems that other modules contain only few functions dealing with
binary data and implementation is in early stage we might decide to
switch other modules to use hexBinary instead. What others thinks?

> I think converting between hexBinary and base64Binary should be
> pretty much a no-op for most processors: the internal representation
> of the value is likely to be an immutable byte array, and conversion
> just means creating a new wrapper around the byte array. But it's a
> user inconvenience. Actually for input parameters, I don't see why we
> shouldn't accept either form.

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).

     Jirka



-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
------------------------------------------------------------------
    Bringing you XML Prague conference    http://xmlprague.cz
------------------------------------------------------------------