|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Text/xml with omitted charset parameter
> > > So is it the case, then, that the default for everything in the text/* > > tree must be ASCII or 8859-1? It's not possible for the subtype text/xml > > to provide a different default than the type text? > > The whole point of registering a format under text/* is that a dumb > interpreter can treat it as plain text, expecting CR/LF line terminators not > too infrequently, if it doesn't know what to do with it. Furthermore, > unless the charset parameter says otherwise it can treat it as ASCII. > the rock-bottom Internet interoperability default. > > Dumb interpreters rarely, if ever, should treat XML as plain text (displaying > it as-is, for example). My understanding so far... - text/xml is the most ubiquitous HTTP content type for xml. - if absent, the official default charset for text/xml is us-ascii - therefore the charset parameter MUST be specified if the content is UTF-8 - many HTTP servers don't conform to this - most xml processors (ours included) don't conform to this My question is, what is the rationale for this 'standard'? Does it actually make any sense for an xml processor to conform? My thinking goes like this. If the xml entity contains only us-ascii then it makes no difference if the xml processor treats it like UTF-8. On the other hand, if the xml entity contains UTF-8 characters, then a "non conformant" processor will read it correctly, whereas a "conformant" one must reject it. It appears in this case that non-conformance has only positive side-effects. Perhaps I'm missing something? Regards ~Rob --- Rob Lugt ElCel Technology http://www.elcel.com/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








