RE: xinclude using xpointer

Thanks for the comment; please accept our apologies for taking so long
to resolve this issue.

> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: Thursday, June 21, 2001 11:33 AM
> To: www-xml-xinclude-comments@w3.org
> Subject: xinclude using xpointer
> 
> I just noticed that XInclude normatively references XPointer.
> 
> To me, this is a conceptual problem.  It precludes the simple
> equation of <xi:include ...> elements to commonly understood
> processes such as the #include of a C/C++/... preprocessor,
> or "external entities without needing DTDs", because it requires
> substantial processing to identify the node subset which an
> optional XPointer reference supports.
> 
> Or to put it differently, it places a rather complex processing
> model (an extended XPath) into a step that should instead be
> conceptually simple.  The XPointer-based inclusion would most
> naturally be a (new) type of XLink.

XPointer is an addressing mechanism, much lower-level than XLink
processing, which is supports application-level behavior.  XInclude is
low-level in that it can be performed at a generic layer, without
invoking any application-specific semantics.  Perhaps our term
"low-level" is too subjective.

> As it says in section 1.1 of the XInclude WD, "XInclude
> processing occurs at a low level".  Perhaps the authors of
> that sentence read something very different into that phrase;
> I'm used to seeing "low level" used to mean something very
> different from the quantity of processing that XPath/XPointer
> requires.
> 
> In terms of the document, I think my preferred change would
> be making fragment IDs in the "href" attribute be illegal, thus
> making XInclude suitable for "low level" implementations.

The WG was unwilling to give up XPointer support, as partial document
inclusion is a major motivator for XInclude.

> Related:
> 
> - If it's truly "low level", it should be in the XML
>   namespace; "xml:include", not "xi:include".

We considered this but felt a different namespace was best for
versioning reasons.

> - The content model should be defined explicitly; I'd
>    prefer EMPTY as the requirement.

We considered this as well but felt that there was little benefit in
limiting the evolvability of XInclude in this way.

> - The relationship to DTD processing needs to be specified,
>   not "undefined"; if this isn't trying to change the XML 1.0
>   specification, then only one relationship is possible.

Not really.  XInclude is given an infoset, which may have DTD processing
already performed.  There is no need to further define our relationship
to DTD validation - so we didn't.  We also didn't want to preclude
processors that perform DTD validation (and augmentation) upon an
infoset, even though there is no standard that describes this in an
interoperable way.

> Sorry I didn't notice this stuff earlier, but these do seem
> like significant problems with the current draft.

We do appreciate the "bootstrap" problem you've identified with
XPointer.  We will add a note to the effect that XPointer uses the XPath
data model largely because the Infoset was not a recommendation at the
time. The mapping between the XPath data model and the Infoset is
straightforward an XPath 1.0 erratum is forthcoming which demonstrates
this). It is also straightforward to map locations in the XPath data
model to the corresponding location in the Infoset.

Also, we recognize that XPointer support is the largest part of XPointer
support, and will keep our eyes on this issue during the CR phase.

- Jonathan

Received on Wednesday, 15 August 2001 17:14:05 UTC