RE: Architectural problems of the XInclude CR

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,
Jonathan Marsh

Received on Friday, 9 May 2003 19:06:53 UTC