Re: Changes checked in to son-of-3023

On Sat, 07 Nov 2009 00:31:24 +0100, Chris Lilley <chris@w3.org> wrote:

> SP> Sorry to chime in this late, but I don't understand why we don't  
> just fix
> SP> the text/xml encoding problem by saying that it's equivalent to
> SP> application/xml instead of keeping a requirement that all  
> implementors
> SP> will continue to ignore?
>
> That suggestion has been made before, by Anne van Kesteren, and is  
> discussed in appendix a.16
>
> http://www.w3.org/2006/02/son-of-3023/latest.html#anchor44
>
> Briefly, it would require updating the HTTP and MIME specifications,  
> which seems like a lot of work.

I think HTTP and MIME should be fixed, but I think that shouldn't be a  
blocker for redefining text/xml.


> Over on ietf-types@alvestrand.no Anne suggested fixing this, but  
> concluded that it would require "infinite time" :)
>
> SP> (Implementors ignore it because there is a
> SP> non-trivial legacy (mostly feeds) with charsetless text/xml content  
> that
> SP> uses non-us-ascii characters and specify the encoding with the XML
> SP> declaration or expect the default to be UTF-8.)
>
> I agree, its awkward, and the "obvious" solution (just believe what the  
> XML document, which is self describing, says) unfortunately clashes with  
> some fundamental IETF specs. The text/* top level type does not do what  
> many people believe it does.

So? Why do we care about conforming to IETF fundamentals that are ignored  
by implementations?


> Given that, unless someone has the energy to fix that situation, then  
> for xml types it seems easier to deprecate text/* and use application/*  
> which does not have that problem.

Deprecating text/xml does not remove text/xml legacy, so doesn't fix the  
problem.


> text/html fixes it in a different way, by documenting the encoding  
> sniffing strategy.

Why can't text/xml do the same?

-- 
Simon Pieters
Opera Software

Received on Friday, 6 November 2009 23:43:59 UTC