CRLF in <string> -- XML vs XML-RPC

I'd like to bring up again a favorite topic on this list: the line of the
XML-RPC spec that attempts to say you can put arbitrary bytes in a 
<string> element.

Those who have followed this discussion know that this is at odds with
another important statement in the spec that an XML-RPC message is XML.
The problem is that if if it's XML, then the contents of a <string>
element are characters and the XML spec says a lot about how they're
interpreted and there's no obvious way to put arbitrary byte data in
there.

One area where it's particularly hard to stretch XML to cover this
binary data idea is "control character" data, because while it's easy
to assume that you would send the byte 0x41 as the XML character
sixty-five, there's no obvious way to send the byte 0x00, because
there is no XML character zero.  But on the other hand, you can imagine
an XML character zero and some implementations do.

But there's one other area that causes trouble: CRLF.  XML says when
an XML processor sees "<string>\r\n<string>" (\r and \n here are two
characters, in the C notation), it should present to the XML application
"\n".

But the binary data concept would suggest that the XML-RPC application
should see "\r\n".

Previous discussion seems to reach the consensus that it's better to
follow XML than some interpretation of that misguided paragraph in the
XML-RPC spec.  One good reason to do this is so you can use standard
XML processing software.

So, enough of the background.  I'm posting because I have recently been told
that many or most XML-RPC servers see "\r\n" at the XML-RPC application
level.  So I want to poll: In existing implementations, if
<string>\r\n</string> comes over the wire, does the XML-RPC application
code see "\r\n" or "\n"?  And does the implementation use standard
XML parsing code or custom XML-RPC code?

On the sending side, you can defeat XML's attempts to normalize line
endings by sending the five characters &#x0d instead of the character
\r.  That brings you closer to the spirit of the "binary data" paragraph
in the XML-RPC spec.  Does anybody do that?

I'll start.  I maintain the XML-RPC For C/C++ libraries.  As far as I
know, they have always presented \r\n to the application as \n on the
receiving end, and it's because they use Expat and Libxml2 XML
parsers.  On the sending side, if the application presents a string
containing "\r\n" in the value for a <string>, those two characters go
onto the wire.

-- 
Bryan Henderson                                   San Jose, California


 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/xml-rpc/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> 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/