RE: Architectural problems of the XInclude CR

OK, I didn't realize that those were intended to be additional comments,
rather than outlining a solution space for Murata-san's original
comment.  I'll bring them to the WG.

> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Sent: Thursday, January 16, 2003 4:11 PM
> To: www-xml-xinclude-comments@w3.org; www-tag@w3.org
> Subject: Fwd: Architectural problems of the XInclude CR
> 
> 
> 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.
> 
> http://lists.w3.org/Archives/Public/www-tag/2002Dec/0250.html
> http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2002Dec/
> 0009.html
> 
> 
> ====== 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
> 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
> ====== 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:23:19 UTC