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

Re: Architectural problems of the XInclude CR

From: Elliotte Rusty Harold <elharo@metalab.unc.edu>
Date: Fri, 27 Dec 2002 19:08:32 -0500
Message-Id: <p04330100ba3299e5a950@[]>
To: "MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp>, www-xml-xinclude-comments@w3.org
Cc: www-xml-linking-comments@w3.org, www-tag@w3.org

At 4:48 PM +0900 12/27/02, MURATA Makoto (FAMILY Given) wrote:
>I think that the XInclude CR has significant problems and that
>it should not become a recommendation in its current form.
>1) XInclude ignores the media type (and probably the charset
>    parameter) associated with resources
>When parse = "xml" is specified, XInclude always assumes that the
>media type is text/xml and the fragment id is an XPointer.  When parse
>= text" is specified, XInclude always uses text/plain in interpreting
>fragment identifiers.  It is unclear whether or not XInclude respects
>the charset parameter of the original media type.  I would thus argue
>that XInclude conflicts media type RFCs and architectural
>principles of W3C (2.4. Fragment identifiers of "Architecture of the
>World Wide Web", Draft 15 November 2002).

I deduce that you want to have the MIME type override the parse attribute?

For parse="xml", maybe that's correct. For parse="text", though, I 
very much disagree with that. I often use XInclude to text-include 
XML documents, including those served with MIME type  text/xml and 
application/xml, source code examples for my books and presentations. 
I want to keep doing that. I think of the parse attribute as more an 
instruction to the processor than any identifier of type. Different 
documents (or even the same document in different places) may want to 
include the same document as text in one place and XML in another.

>2) XInclude uses text/xml rather than application/xml
>Most XMLers prefer application/xml to text/xml, since XML documents
>are not readable by casual users (see RFC 3023).  Some people even
>propose to drop text/xml.  I believe that application/xml should be
>used, even if my first comment is turned down.

I think the sections you are referring to are in 4.2 where it talks 
about coercing resources to text/xml; e.g.

When parse="xml", the include location  is dereferenced and the 
resource is fetched, coerced to text/xml, and an infoset is created.

Looking at those sections now, I think this phrasing is unclear. I 
don't know what it means to "coerce" something to text/xml. I would 
prefer to say that the resource is parsed as XML and leave MIME types 
out of this section completely.

>3) XPointer is not a set of W3C recommendations yet
>When the final decision on the set of XPointer specifications is made,
>XInclude should be modified.

I'd go further. Until such time as XPointer is a final rec (which may 
never happen) or until XInclude removes its dependence on XPointer, 
XInclude should not advance beyond CR. There's been a lot of pushback 
on XPointer lately, and it's not at all clear that this is the way to 

| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
|           Processing XML with Java (Addison-Wesley, 2002)          |
|              http://www.cafeconleche.org/books/xmljava             |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA  |
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
Received on Sunday, 29 December 2002 02:46:08 UTC

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