Comments on XInclude CR draft

Markup Technology Ltd comments on the XInclude CR draft.

XPointer subsetting:

We have found that we have frequent need for two particular forms of
XPointer: ranges, and pointers ending "/*" to allow the inclusion of
the children of an element.  We would not therefore support a subset
of XPointer that did not include these.

But more generally we do not believe that XInclude should define a
subset of XPointer; XInclude should use whatever is chosen by IETF as
the interpretation of fragment identifiers in text/xml documents.

Section 3.1:

It is not clear whether the use of an encoding not supported by the
implementation is a resource error (and so whether it should result
in fallback processing).

Section 3.2:

The paragraph before the DTD fragment refers to "xi:include" when it
means "xi:fallback".

Section 4.2:

It is not clear whether the specification requires XInclude processing to
be performed on included infosets before interpretation of the XPointer.
In particular, is the following example required to work:

  <xi:include href="book.xml#xpointer(//chapter[1]/figure[1])"/>

where book.xml contains:
  
  <book>
   <xi:include href="chapter1.xml"/>
   <xi:include href="chapter2.xml"/>
   <xi:include href="chapter3.xml"/>
  </book>

and chapter1.xml contains:

  <chapter>
    ...
    <figure>...</figure>
    ...
  </chapter>

If the infoset for book.xml is not XIncluded before processing the
XPointer, the chapter and figure elements will not be present.

Section 4.5.1:

Since the second paragraph explains how duplicates may be found even
with different system identifiers, surely the third paragraph should
refer to entities with the same names that are not duplicates, rather
than to entities with different system identifiers.  Similarly for
notations in section 4.5.2.

Section 4.5.4:

We believe this entire section (Namespace Fixup) is misguided.  The
[in-scope namespaces] from the include parent have no necessary
relation to the included items, and the problem of serializing items
who don't have all their parent's [in-scope namespaces] is being
addressed in XML Namespaces 1.1.

Requiring the adjustment of [namespace attributes] to match [in-scope
namespaces] imposes a cost which may well be unnecessary, and can be
left until serialization (as in XSLT).

Section 4.5.5:

It is undesirable to introduce absolute URIs into documents which did
not have them before XInclusion.  Where the included document is
specified by a relative URI, the xml:base attribute should also be a
relative URI where possible.

Received on Tuesday, 30 April 2002 11:52:57 UTC