- From: Christian Grün <christian.gruen@gmail.com>
- Date: Thu, 4 Jul 2013 20:51:33 +0200
- To: John Lumley <john@saxonica.com>
- Cc: Florent Georges <fgeorges@fgeorges.org>, Adam Retter <adam@exist-db.org>, Jirka Kosek <jirka@kosek.cz>, Michael Kay <mike@saxonica.com>, EXPath CG <public-expath@w3.org>
>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 > > >
Received on Thursday, 4 July 2013 18:52:20 UTC