- 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