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.

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.

Related:

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

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

- 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.

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

- David Brownell

Received on Thursday, 21 June 2001 14:37:56 UTC