- From: Florent Georges <fgeorges@fgeorges.org>
- Date: Wed, 3 Jul 2013 19:57:10 +0200
- To: Michael Kay <mike@saxonica.com>
- Cc: EXPath CG <public-expath@w3.org>
On 3 July 2013 19:39, Michael Kay wrote: >> 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? > I think there's a considerable risk that a user who gets a base64 > value (say) from somewhere would pass it to a method that accepts > hexB on one implementation and b64B on another, forgetting to invoke > the conversion, and thus producing non-portable code. Sorry, I don't understand this one. Could you expand a little bit on it, please? > And I don't think it solves the problem of passing untypedAtomic (or > an untyped node). But if there is no implicit conversion from untypedAtomic to binary item, then a user would always have to call an explicit converter, wouldn't he? If the signatures are modified to, say: bin:binary-and($a as bin:binary, $b as bin:binary) as bin:binary then trying to pass an untypedAtomic item as a parameter would be an error. But there would be a converter function to convert an untyped item or node to bin:binary, by interpreting it as lexical hex binary or as lexical base64 binary. Regards, -- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/
Received on Wednesday, 3 July 2013 17:57:56 UTC