- From: Chris Lilley <chris@w3.org>
- Date: Sat, 7 Nov 2009 00:31:24 +0100
- To: "Simon Pieters" <simonp@opera.com>
- CC: public-xml-core-wg@w3.org
On Saturday, November 7, 2009, 12:23:10 AM, Simon wrote: SP> On Fri, 06 Nov 2009 23:20:08 +0100, Chris Lilley <chris@w3.org> wrote: >> Hello public-xml-core-wg, >> Following our productive meeting yesterday, I have edited in the changes >> we agreed and the result is available at >> http://www.w3.org/2006/02/son-of-3023/latest.html 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. 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. 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. text/html fixes it in a different way, by documenting the encoding sniffing strategy. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Friday, 6 November 2009 23:32:04 UTC