Architectural problems of the XInclude CR

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).

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.

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.

4) XInclude blesses XPointer as fragment identifiers of text/xml,
   while RFC 3023 (XML media types) does not.

RFC 3023 does not normatively reference to XPointer.  It simply
mentions XPointer as a possibility.  However, XInclude uses XPointer as
fragment identifiers of text/xml.  Before XInclude becomes a W3C
recommendation, a new RFC for XML media types should be developed and
XPointer should be registered as fragment identifiers of XML media types.

-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>

Received on Friday, 27 December 2002 02:49:30 UTC