W3C home > Mailing lists > Public > www-tag@w3.org > October 2003

Re: Rough sketch for an I-D (a successor of RFC 3023)

From: François Yergeau <francois@yergeau.com>
Date: Thu, 30 Oct 2003 20:36:17 -0500
To: Chris Lilley <chris@w3.org>
Cc: MURATA Makoto <murata@hokkaido.email.ne.jp>, www-tag@w3.org
Message-id: <3FA1BC91.4010805@yergeau.com>

Chris Lilley a écrit  :
> On Wednesday, October 29, 2003, 5:24:57 PM, MURATA wrote:
> MM> - the MIME canonical form with short lines delimited by CR-LF, making
> MM>   UTF-16 and UTF-32 impossible
> 
> MM> - Casual users will be embarrassed if XML is displayed as text, while
> MM>   experts can certainly save and then browse XML documents.
> 
> MM> - Worries that the absence of the charset parameter of
> MM>   text/xml and text/*+xml is particularly harmful, since the
> MM>   default of that parameter is US-ASCII
> 
> Yes, that is particularly harmful. If MIME headers are given
> precedence and treated as authoritative, it makes every text/xml
> document that uses any characters outside ASCII be not well formed.

Yes, harmful and, IMHO, the main reason for deprecating text/xml and 
friends.  I'm just wondering if it wouldn't be possible to remove the 
cause instead of the effect: changing the default charset from US-ASCII 
to look-inside-the-doc, like it currently is for application/xml.

Would it be possible for 3023bis to say that?  It certainly is the case 
already for text/html, in effect if not in the specs.  Downsides?

The other arguments are not really strong, IMHO.  In fact the second one 
is more a statement that we wouldn't lose big by deprecating text/xml, 
not an argument *for* deprecating it.


> Firstly, the charset parameter and the xml encoding declaration should
> never differ, because otherwise the document is only well formed in
> transit and not when processed on the server or when saved to the
> client.

Clients should be explicitly encouraged to fix the encoding declaration 
when saving locally.

-- 
François
Received on Thursday, 30 October 2003 20:37:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:22 GMT