Re: unicode

>Some XML-RPC implementations support unicode and others don't.

It's not an XML-RPC implementation if it doesn't use unicode.  the
XML-RPC spec says XML, and XML says unicode.  But I'll accept, "Some
so-called XML-RPC implementations don't use unicode."

The reference Ernst made to non-Unicodeness of XML-RPC has to do with
a bizarre statement that was in the XML-RPC spec long ago with respect
to the meaning of the value of a <string> element.  It said it was
ASCII characters.  The reason it's bizarre is that an XML document is
composed of characters of text, not bits.  So the value of <string> is
characters of text.  ASCII is an encoding of characters (of text and
control stuff) into bits.  There's no sane way to apply ASCII to the
definition of <string>.

(In XML-RPC, encoding of characters into bits happens two layers below
the definition of <string>).

I don't see how that nonsense ASCII statement from the spec can really
have affected implementations.  When you look at how reluctant Dave
Winer has been to change the spec and the fact that he did retract the
ASCII thing strongly suggests that the ASCII thing had had no
practical effect at that time.

For _maximum_ interoperability, of course, one would also want to
tolerate common XML-RPC subsets such as an ASCII-only server.  In that
case, the client would limit itself to UTF-8 encoding and in <string>
values, use only the printable characters found in ASCII.  (I pick on
<string> here only because it is the only place in XML-RPC where you
have the opportunity to use any other characters).  And the same
applies to REST-RPC or any other protocol that might conceivably be
implemented by a lazy person.


The spec still contains the troublesome statement that a <string>
value can encode a binary value, without any specification of what
code it should use.  So what's the point?  And why would anyone want
to, since there is <base64> for that?

I can see that a naive programmer using low level tools could
accidentally implement an encoding whereby a user could send an
arbitrary bit string through <string> and the same bit string would
arrive at the other end.  (In fact, I think my own C clients and
servers can do this).  But it wouldn't be reliable enough to be
considered a standard -- the other end might actually know something
about Unicode and take the XML standard seriously, and then you'd be
hosed.

The only practical, interoperable, implementation of the XML-RPC spec
must ignore that statement about binary data in <string> and assume
the value of <string> is just simple text.

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/