W3C home > Mailing lists > Public > www-xml-linking-comments@w3.org > October to December 2002

Re: Architectural problems of the XInclude CR

From: Daniel Veillard <daniel@veillard.com>
Date: Mon, 30 Dec 2002 01:08:13 +0100
To: "MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp>
Cc: Elliotte Rusty Harold <elharo@metalab.unc.edu>, www-xml-xinclude-comments@w3.org, www-xml-linking-comments@w3.org, www-tag@w3.org
Message-ID: <20021230010813.N20868@daniel.veillard.com>

On Mon, Dec 30, 2002 at 08:02:04AM +0900, MURATA Makoto (FAMILY Given) wrote:
> On Sun, 29 Dec 2002 13:09:33 -0500
> Elliotte Rusty Harold <elharo@metalab.unc.edu> wrote:
> > 
> > How then do you propose to handle the use-case of including a 
> > text/xml or application/xml document as an example in a book like 
> > Processing XML with Java?
> As I wrote in my previous mail, I do not oppose to textual inclusion of 
> text/xml or application/xml MIME entities.  I oppose to misinterpretation of 
> interpret fragment identifiers.

--- XML Core hat off, libxml/libxslt implementor hat on ---
  Considering that a lot of use case are for entities fetched from
disk, and that when fetched over HTTP the Mime Type for XML resources
is usually set in very wrong ways, I would say that in that case
the author (of the including document) should be given more trust.
He is the one designing the fragment identifier, and expect a given
type of resource, I don't think it is an heresy to consider that the
Mime-Type he is expecting for the resource (and for which he designed
the fragment identifier) is a key information in the processing of this
resource. Even if the Mime Type returned by the HTTP server is slightly
different or if the Mime Type for the resource simply doesn't exist 
(often the case when fetching from a filesystem or a resource cached in
a Catalog ...).


Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Received on Sunday, 29 December 2002 19:08:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:14 UTC