RE: Architectural problems of the XInclude CR (David Orchard) writes:
>> XInclude doesn't begin to ask this range of questions, much less
>> propose an answer.  That doesn't strike me as anywhere near careful.
>It makes the cast, and the new "type" explicit.  After that, caveat
>emptor. Much better than guessing or having default rules.  There's
>not much more that XInclude per se could or should do.

Things that "XInclude per se could or should do":

* Mention content negotiation and its potential impact on XInclude

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

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

Beyond that, it might be nice to provide an explanation of "when
XInclude processing happens" that's more substantial than "whenever",
but that's veering beyond the boundaries of this discussion as
Murata-san originally raised it.

Is that a reasonable start?  Caveat emptor is pretty lousy grounds for
writing specifications.

Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down! --

Received on Monday, 30 December 2002 14:52:23 UTC