- From: Simon St.Laurent <simonstl@simonstl.com>
- Date: Mon, 30 Dec 2002 14:53:03 -0500
- cc: www-xml-xinclude-comments@w3.org, www-xml-linking-comments@w3.org, www-tag@w3.org
dorchard@bea.com (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 processing. * 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! http://simonstl.com -- http://monasticxml.org
Received on Monday, 30 December 2002 14:52:23 UTC