W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > January 2003

Fwd: RE: Architectural problems of the XInclude CR

From: Simon St.Laurent <simonstl@simonstl.com>
Date: Thu, 16 Jan 2003 19:11:22 -0500
To: www-xml-xinclude-comments@w3.org, www-tag@w3.org
Message-ID: <r01050400-1023-36448F6429B011D781E20003937A08C2@[]>

Jonathan Marsh wrote:
>The XML Core WG has resolved the remaining issues you raise as
>indicated below.  If you disagree with these resolutions, please
>respond promptly so we can present the issues as unresolved in our
>request for PR.  We will assume that you agree with our resolutions if
>we don't hear from you by Jan 24th - but would much prefer an explicit
>acknowledgement (positive or negative) because of the importance of
>these issues and our desire to make sure the Director is fully aware
>of any disagreement surrounding them.

I'll leave it to Murata-san to give or withhold his assent.  However,
there is another set of issues which has never been addressed to the
best of my knowledge.  The Director may wish to be aware of these
(related) disagreements as well.


====== Forwarded Message ======
Date: 12/30/02 2:53 PM
From: simonstl@simonstl.com (Simon St.Laurent)
To: www-xml-xinclude-comments@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

* 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
====== End Forwarded Message ======
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 Thursday, 16 January 2003 19:10:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:32 UTC