W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > February 2004

RE: accept and accept-charset attributes

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 25 Feb 2004 15:55:42 -0800
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA202B95528@RED-MSG-30.redmond.corp.microsoft.com>
To: "Elliotte Harold" <elharo@metalab.unc.edu>, <www-xml-xinclude-comments@w3.org>

We agree, and will remove the accept-charset attribute from XInclude.

> -----Original Message-----
> From: www-xml-xinclude-comments-request@w3.org
> comments-request@w3.org] On Behalf Of Elliotte Harold
> Sent: Thursday, January 29, 2004 1:15 PM
> To: www-xml-xinclude-comments@w3.org
> Subject: Re: accept and accept-charset attributes
> I no longer think the three accept attributes are particularly
> to implement, at least in Java. Once I sat down and implemented them,
> they were quite straight-forward, and required only minor, non-public
> changes to my code.
> I do, however, wonder about the choice of the specific three
> we've been given. accept-language is a clear winner. You might well
> to choose the French or English or Chinese version of a resource. This
> one makes sense. The use case is obvious and compelling.
> accept is more questionable. Still, especially when parse="text", I
> see asking for the xml or html version of a resource as appropriate if
> were trying to write a tutorial about one language or the other. It's
> bit of a stretch but the use-case is there.
> accept-charset makes no sense to me whatsoever. Almost always the
> document returned by a server in the requested charset will be a
> straight transcoding of the same document in a different charset. It
> seems very unlikely (and probably a bug) if the document content
> from one charset to the next. Furthermore, whatever charset the
> is served in, the XML parser will simply transcode into its native
> format. No artifact of the charset should be left after resolution.
> Perhaps the client wishes to ask for only those charsets it knows how
> process? Perhaps, but this decision is much beter made by the client
> software than the document. For instance, I might wish to code my
> implementation such that it can accept all charsets Java understands.
> Daniel Veillard might wish to code his implementation so that it
> only those charsets libxml understands. I don't see why either of our
> implementations should be controlled by what's in the document. The
> document does not know whether it will be processed by libxml, XOM,
> XInclude.NET, something else, or all of the above. The decision about
> which charsets to accept should be left to the processor, not embedded
> in the document.
> Therefore I am making a formal comment requesting that the
> accept-charset attribute be eliminated from XInclude, and that
> processors be allowed to make their own choice of charsets to be
> negotiated with the server.
> --
> Elliotte Rusty Harold
Received on Wednesday, 25 February 2004 18:55:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:34 UTC