Re: RFC: REST-RPC

On 21 Apr 2006, at 10:13, Gaetano Giunta wrote:

> A bit more insight into the unicode pbls:
>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]]On Behalf
>> Of John Wilson
>> Sent: Friday, April 21, 2006 8:28 AM
>
> ...
>
>> 'Any characters are allowed in a string except < and &, which are
>> encoded as &lt; and &amp;. A string can be used to encode
>> binary data.'
>>
>
> A string in fact can NOT be used to encode binary data. the problem  
> is twofold:
> + control chars (except TAB, CR and LF) are not valid inside xml  
> documents, ie. sending binary will break xml

Qite so

> + in xml documents the CRLF will (could?) be normalized, ie.  
> standard xml encoders will break binary data

A conforming XML processor will always normalize CRLF however If the  
CR and LF characters are represented as character references then the  
processor is required to leave them alone.

> + charset entities in received xml should be decoded by the xml  
> parser and passed to the xmlrpc toolkit in their standard  
> representation, ie. standard xml parsers will break binary data

I don't think any sane person believes that it's possible to transfer  
arbitrary binary data as Unicode characters in an XML document :)

>
>>
>> My recommendation to implementers is generally to emit XML with no
>> encoding declaration and to use numeric character references for
>> those Unicode characters with code points > 0X7F. This seems to
>> maximise the interoperability.
>
> This is the best solution I could come up with, too.
> The only drawback is that there is no guarantee that the charcters  
> sent will be 'understood' succesfully by the receiver (e.g. when  
> sending a japanese unicode char to some program that uses iso-8859  
> internally).

Yes but the advantage is that if they are not understood the other  
end will break. Other options run the risk of the other end silently  
accepting garbled data.
>
> In fact, if you read the HTTP specs, you will find out that for  
> text/xml mime type (the mimetype specified by xmlrpc), when no  
> charset encoding is present in the http headers (or xml prologue),  
> you must use ascii only, anyway (see RFC 3023).

Yes but that's an old problem - if implementations really honoured  
RFC 3023 in full quite a lot of the Web would break!
>
> So the approach used in the php-xmlrpc lib is the following:
>
> for sending:
>
> default:
> encode all emitted Unicode characters with code points > 0X7F to  
> their unicode numeric character reference, send payload using 'text/ 
> xml' mime type and no charset spec in the xml prologue.
> The payload is granted to be parsed by any xml parser, because it  
> is valid ascii, valid iso-8859-1 and valid utf8 at the same time.
>
> special cases:
> When the user specifies a desired charset for the emitted xml, the  
> payload is encoded to the chosen charset, and charset encoding  
> declarations are added to both the http content-type header and the  
> xml prologue.
> This breaks 'slightly' the spec (which mandates 'text/xml' with  
> apparently no charset allowed) but maximizes the chances of the  
> receiver getting the charset right.

That looks a pretty good way of working
>
> for receiving:
>
> 'guestimate' the charset of the incoming payload by looking at http  
> content-type and xml prologue. If none is found assume UTF-8 by  
> default, because, despite what the specs say, it is what most  
> implemantations out there will be sending (but the user can  
> configure it to use iso-8859-1 as default if he prefers)

I presume you use the heuristics described in the XMl spec to guess  
the encoding of the document with sufficient precision to read the  
xml declaration (i.e. you know that the first byte is either part of  
the BOM or all or part of the encoding of '<')

John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org




 
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/