RE: Architectural problems of the XInclude CR

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 can see potential for problems only in the following areas:

1) An author includes a resource that is not XML, but in some other
format that happens to parse successfully with an XML parser, and that
has a fragment syntax that is both a legal XPointer, and successfully
points to something within the resource.  Such an unlikely combination
of factors would lead to a successful inclusion rather than an explicit
failure.  Such a "false positive" might cause problems in an application
dependent upon a specific structure of included information, but so
poorly designed that it doesn't validate to ensure against just this
kind of abuse.

2) Someone registers a media type as application/*+xml but abuses the
+xml convention by developing a fragment identifier syntax that reuses
XPointer syntax but applies different semantics.  An author includes a
resource of this type, and then is surprised that the pure XPointer
semantics is enforced.

Both of these scenarios seem incredibly remote to me.  Are there other
potential problems that could arise?

Another way to uncover the heart of your concern may be to consider it
this way: If we stripped the fragment ID out and put it in a separate
attribute, thereby end-running RFC 2396, would there still be an
architectural issue?

> 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 believe this is a trivial editorial change.

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

The XML Core WG is still considering our PR timing in relation to the
XPointer specifications.  You are not the only one to voice this
concern.  Voting on moving the XPointer specifications to Recommendation
ended December 13th, so I would expect this comment will become moot
shortly.

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

Is there a real possibility that XInclude and the media-type
registration can get out of sync once (if) XPointer becomes a
Recommendation?  Can you share any plans you may have for such an update
with us?  If there are no such plans, it would be silly for XInclude to
take such a dependency.

- Jonathan Marsh

Received on Friday, 3 January 2003 18:21:38 UTC