Lists Home |
Date Index |
- From: Chris Lilley <email@example.com>
- To: MURATA Makoto <firstname.lastname@example.org>
- 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
> (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
> 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.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)