W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > July 2002

RE: Comments on XInclude CR draft

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 17 Jul 2002 13:25:04 -0700
Message-ID: <330564469BFEC046B84E591EB3D4D59C06CCAD74@red-msg-08.redmond.corp.microsoft.com>
To: "Richard Tobin" <richard@markuptechnology.com>, <www-xml-xinclude-comments@w3.org>

Responses below:

> -----Original Message-----
> From: Richard Tobin [mailto:richard@markuptechnology.com]
> Sent: Tuesday, April 30, 2002 8:53 AM
> To: www-xml-xinclude-comments@w3.org
> Subject: 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.

The XML Core WG has received a number of comments on XPointer support in
XInclude, most suggesting some sort of XPointer subset.  The recent
factoring of XPointer has given the WG the opportunity to simplify
XInclude implementation without creating our own subset of XPointer. The
WG has decided to require support for the XPointer Framework [1], and
the XPointer element() Scheme [2].  Support for the XPointer
xpointer() Scheme [3] and other schemes developed in the future would be

[1] http://www.w3.org/TR/xptr-framework/
[2] http://www.w3.org/TR/xptr-element/
[3] http://www.w3.org/TR/xptr-xpointer/

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

The WG clarified this by deciding that unsupported encodings will enable
fallback processing, since they don't impact streamability and fall into
the category of "resources that are unavailable for any reason".

> 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
> be performed on included infosets before interpretation of the
> 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.

We will clarify that recursive inclusion is performed prior to
evaluating XPointer.

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

Agreed.  We will replace the third paragraphs in 4.5.1 and 4.5.2 with:
"It is a fatal error to include [unparsed entity/notation] items with
the same name, but which are not determined to be duplicates."

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

We have removed mandatory namespace fixups.  We warn users that
[namespace attributes] is not guaranteed to be reliable after inclusion,
and therefore recommend against it.  We still allow
implementation-defined fix-ups where necessary.

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

Agreed.  We're currently still working on a proposal to accommodate
Received on Wednesday, 17 July 2002 16:25:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:31 UTC