RE: Architectural problems of the XInclude CR

Disposition of your comments by the WG below:

> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Sent: Monday, December 30, 2002 11:53 AM
> To: www-xml-xinclude-comments@w3.org
> Cc: www-xml-xinclude-comments@w3.org; www-xml-linking-comments@w3.org;
> www-tag@w3.org
> Subject: RE: Architectural problems of the XInclude CR


> Things that "XInclude per se could or should do":
> 
> * Mention content negotiation and its potential impact on XInclude
> processing.

I have added a section on content negotiation using an edited version of
the text you originally proposed on this thread.

> * Explain the relationship between "text" and "xml" and the MIME Media
> Type identifiers commonly used on the Web, and explain why XInclude
uses
> this approach rather than the more Web-like approach.  

I now mention that this overrides the usual rules.  I also clarified
that XInclude gives the author priority over the media type instead of
the server to enable features such as the textual inclusion of XML for
display as examples.

> "Coercion to
> text/xml" may be appropriate, but it's an unusual approach for the Web
-
> and no such coercion is mentioned for text.  It's especially
intriguing
> that XInclude references RFC 3023 _only_ in the context of determining
> the character encoding of content to be included when parse="text".

The rules we describe for determining character encoding are slightly
different than those for text/plain, in order to facilitate the
inclusion of working XML examples.  That is, you use the (more accurate)
XML rules when you have already determined that the resource is XML.
Describing text inclusion as coercion to text/plain isn't completely
accurate.

> * Explain explicitly how its reading of URI references overrides the
> usual "MIME media type provides context for fragment identifier
> processing" rules that generally apply to Web content.

Done, as indicated above.

- Jonathan

Received on Friday, 7 February 2003 16:15:02 UTC