Lists Home |
Date Index |
- From: MURATA Makoto <firstname.lastname@example.org>
- To: Chris Lilley <email@example.com>
- Date: Wed, 24 Mar 1999 10:53:00 +0900
XML requires a draconian approach. 100% interoperability for conformant
implementations is most important. Very low interoperability
for non-conformant implementations is acceptable.
As for HTML, users see corrupted documents when the browser chooses
an incorrect encoding. Then, they can tell the correct encoding to
the browser. Thus, it might not be a bad idea to provide 80% interoperability
for conformant implementations and 50% interoperability for non-conformant
implementations. The heuritics in HTML 4.0 is based on such an assumption,
as I see it.
As for XML, recipients of XML might be programs or database systems.
In the worst case, corrupted documents will contaminate the entire
database. A single XML document on the WWW may destroy XML-aware
search engines. Hence, I believe that we need a draconian approach; we
have to ensure 100% interoperability for conformant implementations.
Ideally, it should be possible to point out non-conformant data and
implementations. expat sometimes detects incorrect charsets.
HTTP/1.1 quite clearly says that the charset parameter is authoritative.
If RFC 2376 had said something different, interoperability for
conformant implementations would have been destroyed.
Chris Lilley wrote:
> MURATA Makoto wrote:
> > I believe that IE 5.0 does not conform to RFC2376 (XML Media Types),
> > of which I am a co-author.
> > As for the XML media type "text/xml", the charset parameter in the
> > MIME header is authoritative. Encoding declarations have to be ignored
> > so that transcoding is possible.
> So, if the file is saved to some local browser cache and then re-read,
> it may have no MIME header so the encoding declaration is then
The same thing applies to HTML. The cache must have MIME headers as well.
> Why can't the transcoding proxy also rewrite the encoding declaration,
> since it is rewriting the file anyway? It is trivially easy to find,
> process, and change.
For security reason, transcoding proxies should not rewrite documents.
Moreover, if we mandate embedded encoding signatures for HTML, XML, CSS,
etc., I18N of flat text will become impossible.
I have believed that there is a conssensus in the W3C team and I am quite
puzzled by your response. You might want to speak with Martin Duerst.
> I imagine that someone could take some generic charset-converting code
> and make a n XML-aware transcoding servlet that rewrote the encoding
> declaration in about what, an hour? If someone does this, I will see
> about getting it included in the next Jigsaw version.
Please don't do that.
> > However, IE 5.0 appears to always ignore the charset parameter and use
> > the BOM or encoding declaration only. Therefore, IE 5.0 does not conform to
> > RFC 2376.
> Okay. But does RFC 2376 conflict with the XML 1.0 Recommendation?
As Jon Cowan pointed out, it does not.
> > When the charset parameter is not specified, it is assumed as US-ASCII.
> Wow. So, what this RFC says is that, when used in email and on HTTP, the
> encoding declaration is *always ignored*.
If the media type is text/xml, yes. As for application/xml, we use
the procedure in Appendix F of XML 1.0.
> That is a pretty big change and, frankly IMHO, ill-advised.
Frankly, I am quite surprised that a W3C team member says such a thing
in a public place after an RFC is published.
Chris Lilley wrote:
> Correction: if you are the *administrator* of an Apache server. One of
> the ways in which the Web has changed over the last 5 years is that the
> percentage of Web authors who also administer the site that they serve
> from has dropped from a substantial majority to an insignificant
Are you aware of the "AddCharset" patch developed by W3C Keio? It
allows casual users to configure Apache. Please concact Koga-san at
W3C Keio (firstname.lastname@example.org).
Chris Lilley wrote:
> Please consider points 1 and 2 to be a defect report on RFC2376
These points are clearly in conflict with HTTP 1.1.
Fuji Xerox Information Systems
Tel: +81-44-812-7230 Fax: +81-44-812-7231
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)