Re: 7.9.3 (PR#146)

Hi Michael,

The working group solved this issue indirectly.  We found it necessary to remove
the functions encode() and decode().  Although they seem like they could be
useful, the decode function can produce results that do not fit the XPath data
model's restriction to XML Char, which means that encode() would need to take
illegal string data in order to be fully functional.

Best regards,
John Boyer

> 
> 
>     K. The decode() function needs to define an additional error, for
>     the case where the data can be decoded as a UTF-8 character string
>     but that string contains a character not allowed in XML.
> 
>     The name of the encode() function is much too generic, and should
>     be renamed to something that indicates its purpose more clearly. In
>     the description of the encode() function, "The data string is
>     serialized as UTF-8" is ambiguous - it might mean (a) the parameter
>     must be UTF-8, or (b) the function serializes the input string as
>     UTF-8.
> 
>     Also, UTF-8 is hard-coded. There are other possibilities.
> 
>     The phrase "string of data" is redundant; you can simply say
>     "string".
> 
>     In XPath 2.0, you would probably want to have two functions - one
>     would return the base64 binary representation, the other would
>     return the hex binary representation. Conversion of the binary to a
>     string would be done by the string() function.
> 
>     These two functions are candidates for incorporating into XPath 2.N
>     core. We would be interested in working with you on the design of
>     these two functions.
> 
>

Received on Wednesday, 31 October 2007 20:34:14 UTC