Re: Architectural problems of the XInclude CR

Freeing this from spam defenses...

On Tue, 2003-05-13 at 12:48, MURATA Makoto (FAMILY Given) wrote:
> 
> On Fri, 9 May 2003 16:06:45 -0700
> "Jonathan Marsh" <jmarsh@microsoft.com> wrote:
> 
> > Back in December, you wrote:
> > 
> > > 4) XInclude blesses XPointer as fragment identifiers of text/xml,
> > >    while RFC 3023 (XML media types) does not.
> > > 
> > > RFC 3023 does not normatively reference to XPointer.  It simply
> > > mentions XPointer as a possibility.  However, XInclude uses XPointer
> > as
> > > fragment identifiers of text/xml.  Before XInclude becomes a W3C
> > > recommendation, a new RFC for XML media types should be developed and
> > > XPointer should be registered as fragment identifiers of XML media
> > types.
> > 
> > As you recall, we did not at the time agree to take a dependency upon
> > the (unknown) schedule for such an updated RFC.  But the Director
> > pointed out that we can do this without a normative reference to or
> > schedule dependency on an (as yet non-existent) spec.  The text we
> > crafted is:
> > 
> >   When the resource is transformed to application/xml, the fragment
> >   identifier of the URI reference is interpreted according to the 
> >   fragment identifier syntax defined for application/xml, regardless 
> >   of the pre-transformation media type of the resource. The fragment
> >   identifier indicates a portion of the acquired infoset as the target 
> >   for inclusion. Fragment identifiers containing XPointers of the 
> >   forms described in [XPointer Framework] and [XPointer element() 
> >   scheme] must be supported. XInclude processors optionally support 
> >   other forms of XPointer such as that described in [XPointer 
> >   xpointer() Scheme].
> > 
> > This still presupposes that the fragment identifier for application/xml
> > is at least compatible with the XPointer Framework and XPointer
> > element() scheme, which we needed to enable our conformance statement
> > about these specs.  But we hope you agree with us that this is improved.
> > 
> > Please let us know whether it satisfies your objection to moving
> > XInclude to Proposed Recommendation.
> 
> Thank you for your further consideration.  I am not satisfied however.
> 
> First, I do not understand what you mean by "Fragment identifiers containing 
> XPointers of the forms described in [XPointer Framework] and [XPointer element() 
> scheme] must be supported."  The reason is the conformance section (quoted below) 
> in [XPointer Framework] is quite unclear.  What is your interpretation of "the minimum 
> conformance level of XPointer"?
> 
> 	This specification defines a framework; it does not currently define a
> 	minimum conformance level for XPointer processors. Thus, the information
> 	in this section defines conformance requirements only for the framework
> 	portion of any minimum conformance level.
> ...
> 	Software components claiming to be XPointer processors must conform to
> 	this XPointer Framework specification and any other specifications that,
> 	together with this specification, define the minimum conformance level
> 	for XPointer
> 
> Second, I do not like the idea of making an assumption about the fragment 
> identifier for application/xml.  In my understanding, the first issue prevents 
> us from creating a new RFC for XML media types.
> 
> Cheers,

Received on Tuesday, 13 May 2003 13:53:25 UTC