On Mon, 2005-05-02 at 17:43 -0700, Steve Quint wrote: >At 8:50 PM -0700 5/1/05, Daniel L. Rall wrote: >> >>Ignoring the encoding="..." XML header, that would indeed be valid XML. >>However, when the XML is subsequently processed, the entity-encoded >>value will transformed into ASCII. Since there is no equivalent 7 bit >>ASCII character which fits within that range (e.g. 0x7f is ASCII 127), a >>parse error will be generated. > >I believe it is incorrect for XMLWriter to make any assumptions about >encodings, especially since the encoding is passed in the >constructor.
Hi Steve, can you elaborate on this? Both the XML RFCs and certain encodings dictate what constitutes valid content, and how content must be represented. For instance, certain multi-byte characters simply aren't representable in 7 bit encoding like ASCII -- the only way to deliver'em through an ASCII encoding is to use another encoding which can be represented in ASCII (e.g. base-64). >If I create an instance of XMLWriter that I expect to >support a binary encoding that I passed in the constructor, I >shouldn't have to worry about an encoding related error later on. >Encoding related errors should probably happen at the time I specify >an encoding. How do you recommend that be done, given the content to write isn't available until the writeObject() method is called? It seems to me that you don't know whether the content is representable in your specified encoding until you get the content... This behavior seems reasonably consistent with the JDK, which declares that a Writer can throw an IOException (which UnsupportedEncodingException is an instance of). http://java.sun.com/j2se/1.4.2/docs/api/java/io/Writer.html#write(java.lang.String) >If this is truly the behavior you wish to enforce, and I see no >reason for it, perhaps the Constructor should throw an >UnsupportedEncodingException if the encoding is neither UTF-8 nor >UTF-16. I don't follow you. The XML-RPC spec itself used to dictate that the XML payload must be ASCII. That changed only recently. Thanks for the review! - Dan
