Re: [xml-dev] xml over http - RFC 3023

[Rick Jelliffe <rjelliffe@allette.com.au>]

Andrew Welch wrote:
> But the basic XML contract is that the encoding must be explicitly 
> labelled
>> by the sender (creator of the document) and the recipient should not guess
>> but use the label.  
> Er, ok.  You do realise there is a different expert somewhere else in
> the world saying exactly the same thing about their specialist area.
> (not sure I agree with that analogy either)
>   
I think there are only three points of view floating about nowadays: 1) 
Man can come down from the trees: everything other than UTF-8 and UTF-16 
can be ditched now;  2) Man should stay up in the trees for as long as 
they like: supporting a plurality of encodings proved its practicality, 
so don't fix what isn't broken, or 3) We are still amoeba and we can be 
as sloppy as we like: make XML like HTML with anything goes and 
guesswork, because whenever an idiot wants to do something, they are 
always right.    [I am at a non-doctrinaire position of 1) so 2) is OK.]

> From my naive perspective, I would've thought the web server would
> serve the XML with the correct encoding in the contenttype so I don't
> have to ignore it, and/or I could the XML parser a url and it would
> take care of it.  I'm not sure why I should be reading appendices of
> the spec and writing low-level code for something that should be an
> everyday task.  In that respect, I think, you could argue it hasn't
> succeeded yet
Well, it hadn't succeeded in shaming oops inspiring the HTTP or MIME 
specs into a more workable policy on character sets quickly! The changes 
to HTTP RFC mentioned in this thread would be a good step. 
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/20

I also think that more "text" formats should provide an firstline 
encoding declaration mechanism: eg 
http://www.topologi.com/resources/xtext.html   I think CSS has gone down 
that path too.

Cheers
Rick