- From: Florent Georges <fgeorges@fgeorges.org>
- Date: Wed, 3 Jul 2013 19:31:49 +0200
- To: Michael Kay <mike@saxonica.com>
- Cc: EXPath CG <public-expath@w3.org>
On 3 July 2013 19:07, Michael Kay wrote:
> 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.
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?
For instance, instead of the xs:base64Binary-based example:
let $bin := xs:base64Binary(...)
return
bin:binary-and(
bin:binary-shift($bin, ...),
...)
we'd have:
let $b64 := xs:base64Binary(...)
let $bin := bin:from-base64($b64)
return
bin:to-base64(
bin:binary-and(
bin:binary-shift($bin, ...),
...))
That is, all (binary) parameters and return values of the API use
that implementation-dependent type (let's call it binary item), and
there are entry-/exit-points for all supported formats (from-base64,
to-base64, from-hex, to-hex, etc.)
So an implementation can choose any type that suits its needs best,
without requiring the compatibility with xs:base64Binary, there is no
arbitrary choice between xs:base64Binary and xs:hexBinary, and the
user must explicitly ask for a "serialization" (or any other "final
usage" of a binary item), in order to prevent accidentally adding a
binary item to a tree then back again as a binary item (if we define
that adding a binary item to a tree is an error).
It looks to me it is better from the specification point of view,
from the implementation point of view (but of course I might overlook
some specifics) and even from the user point of view (with a more
"controlled" API).
Regards,
--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/
Received on Wednesday, 3 July 2013 17:49:05 UTC