RE: Architectural problems of the XInclude CR

Back in December, you wrote:

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

As you recall, we subsequently rejected a change to the document, as we
could see no way to enable the XInclude functionality without this
restriction.  We highlighted your continued objection and call to bring
this to the attention of the Director and the TAG in our disposition of
comments.

During our recent Proposed Recommendation review, the Director suggested
that, while it is architecturally suspicious to "cast" a resource to a
new media type, what we are doing is "transforming" from one media type
to another - which is a sounder description of how we relate to the
architecture.  We adopted such terminology, as illustrated by the
following sample:

  When parse="xml", the include location is dereferenced and the
resource 
  is fetched, transformed to application/xml, and an infoset is created.
  The transformation to application/xml allows XInclude to give the 
  author of the including document priority over the server of the 
  included document in terms of how to process the included content; 
  namely, to include a document as either XML or as text.

We would like to know if you feel this is adequate to satisfy your
objection to the publication of XInclude as a Proposed Recommendation of
the W3C.

Thank you,
Jonathan Marsh

Received on Friday, 9 May 2003 18:48:15 UTC