RE: Architectural problems of the XInclude CR

As you are no doubt aware, we addressed the issue of fragment
interpretation by splitting the XPointer from the URI and placing it in
a separate attribute.  This was reflected in a second Last Call release
[1].  We are preparing to enter another Candidate Recommendation, and
wanted to be able to refer to your acceptance of this resolution, but I
can't find such an email in our archives.  Could you confirm that this
addresses your comment?  The latest editor's draft of XInclude is at
[2].

[1] http://www.w3.org/TR/2003/WD-xinclude-20031110/
[2] http://www.w3.org/XML/Group/2004/03/CR-xinclude-20040329/ (member
only)

> -----Original Message-----
> From: Murata Makoto [mailto:EB2M-MRT@asahi-net.or.jp]
> Sent: Thursday, January 16, 2003 8:55 PM
> To: Jonathan Marsh
> Cc: www-xml-xinclude-comments@w3.org; www-xml-linking-comments@w3.org;
> www-tag@w3.org; eb2m-mrt@asahi-net.or.jp
> Subject: RE: Architectural problems of the XInclude CR
> 
> >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
> 
> I agree with the resolutions for (2) and (3), but
> disagree with the resolutions for (1) and (4).
> 
> >>1) XInclude ignores the media type (and probably the charset
> >   parameter) associated with resources
> 
> I see a conflict between XInclude and the WWW architecture
> and ask the TAG and Director to consider this issue.
> 
> >> 4) XInclude blesses XPointer as fragment identifiers of text/xml,
> >>    while RFC 3023 (XML media types) does not.
> >
> >The XML Core WG does not feel holding up XInclude for this purpose is
> >warranted, as there are no candidates for XPointer fragment syntax at
> >this time other than the XPointer features we have identified in the
> >spec.
> 
> I certainly disagree with this decision, which ignores
> IETF.
> 
> Cheers,
> 
> Makoto

Received on Wednesday, 31 March 2004 12:54:54 UTC