[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: IE5.0 does not conform to RFC2376

• From: Chris Lilley <chris@w...>
• To: MURATA Makoto <murata@a...>
• Date: Sun, 04 Apr 1999 15:38:58 +0200

MURATA Makoto wrote:
> 
> David Brownell wrote:
> > True -- but if there's one basic rule that seems safer
> > than another, it's "default to application/xml" rather
> > than "assume ASCII and stick to text/xml"!  :-)
> 
> Or, "Use Apache (probably with the AddCharset patch),
> specify utf-16, and always use UTF-16." 

That is a reasnable choice for a single author to make; it is not a
reasonable choice to impose on all authors everywhere.

> This is my favorite.

But not necessarily everyones favourite. It is a good choice for
Japanese, because Kanji use less bytes per character in UTF-16 than in
UTF-8.


> (In the case that the charset is broken, autodetection of
> UTF-16 is very easy. 

But autodetection should not be required; users can label their
documents correctly.

> In my environment, I added a few lines to the "httpd.conf" file
> of Apache.  They are as below:
> 
> AddType "text/html; charset=shift_jis" htm
> AddType "text/html; charset=shift_jis" html
> AddType "text/html; charset=utf-8"     htm8
> AddType "text/html; charset=utf-16"    htm16
> 
> AddType "text/xml;  charset=utf-16"    xml
> AddType "text/xml;  charset=utf-8"     xml8
> AddType "text/xml;  charset=utf-16"    xml16

Which illustrates my point exactly. You made some private conventions
about filename extensions and you chose to reconfigure your server to
understand those private conventions - and then, it works.

These addtype lines would be quite unsuitable for a web server used by
multiple users with multiple mother tongues.

On the other hand, if the RFC had been written as I suggested, saying
that a charset parameter overode *if present* but that *if absent*, the
rules in the XML recommendation were followed, then you would need no
server reconfiguration and the rules to follow to have the encoding
information correctly conveyed to the client would have been a matter of
public record in the XML recommendation rather than private convention.
A big win for interoperability, if that had happened.

Murata-san, you asked why a W3C team person was criticising this RFC in
public. It is because the mission of W3C is to improve interoperability,
so it is my duty to do so. Regardless of the esteem in which I may hold
the author, I will argue against technical matters if I believe them to
be wrong and to reduce interoperability.

--
Chris

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • Re: IE5.0 does not conform to RFC2376
    • From: MURATA Makoto <murata@a...>

• Prev by Date: Re: IE5.0 does not conform to RFC2376
• Next by Date: Re: DOM
• Previous by thread: Re: IE5.0 does not conform to RFC2376
• Next by thread: Re: IE5.0 does not conform to RFC2376
• Index(es):
  • Date
  • Thread