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

Hi Christian,

In eXist they almost exclusively use base64. I am not sure why, perhaps
because of the relationship with MIME and Multipart... They also provide
functions for going to/from hex.
On 4 Jul 2013 21:51, "Christian Grün" <christian.gruen@gmail.com> wrote:

> From a user point of view, it may be more convenient to have an
> xs:binary super type that includes both xs:base64Binary and
> xs:hex64Binary as sub types (because I have been repeatedly asked by
> XQuery writers why XQuery provides two different types for binary
> data) – but as it has already been pointed out, it’s surely too late
> to add such a type in the XQuery data model. For the sake of
> consistency and orthogonality, and for the optimization strategies of
> XQuery processors, it may be advantageous to restrict functions to a
> stricter type (i.e., xs:base64Binary instead of xs:anyAtomicType).
>
> The more extensions functions we will specify, the more often we will
> stumble upon the same question. In the beginning, I tended to prefer
> xs:anyAtomicType as super type. On the other hand, I get the
> impression that Base64 is the preferred binary type in most existing
> XQuery modules across different implementations.
>
> So I would be interested to hear how existing functions in eXist-db,
> Saxon, Zorba, MarkLogic, … handle function arguments? Do you all use
> xs:base64Binary as standard type, do you allow both types (which is
> what we mostly do in BaseX right now), or do you have functions that
> exclusively accept xs:hexBinary?
>
> Looking forward to your replies,
> Christian
> ___________________________
>
> 2013/7/4 John Lumley <john@saxonica.com>:
> > Florent Georges wrote:
> >>
> >> On 4 July 2013 17:35, Adam Retter wrote:
> >>
> >>>
> >>> Functions should explicitly take xs:base64binary and return
> >>> xs:base64binary because that is the type used in other EXPath
> >>> specs.
> >>>     What if you want xs:hexBinary? Simply, we provide conversion
> >>> functions to/from hex to base64.
> >>>
> >>
> >>   Yes.  I start to think this is probably the most practical approach...
> >>
> >>   - one single type consistently used across the spec
> >>   - no custom type
> >>   - specific entry points (in and out) to use other types
> >
> > On the assumption that the converter functions (bin:base64B-to-hexB(),
> > bin:hexB-to-base64B()) are cheap wrapper implementations (i.e. no bulk
> > transfer of data), then a parallel library for hexBinary could easily be
> > written in pure XSLT.
> >
> > John Lumley
> > john@saxonica.com
> >
> >
> >
>