- 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