XPointer Disposition of Comments

Issue (issue-typo-resource):

From Erik Wilde, and Susan Lesch. Section 1.3 has a typo in the definition of a resource. The definition duplicates some text. It currently reads: "Note that this term and its definition are taken from the basic specifications governing the World Wide Web. Note that this term and its definition are taken from the basic specifications governing the World Wide Web, such as IETF RFCs [IETF RFC 2396], [IETF RFC 1738] and [IETF RFC 1808]. "

This issue has no corresponding entry in the XPointer issues list.

Resolution: Accepted, the text should read: "Note that this term and its definition are taken from the basic specifications governing the World Wide Web, such as IETF RFCs [IETF RFC 2396], [IETF RFC 1738] and [IETF RFC 1808]. "

Issue (issue-typo-contexts):

From Susan Lesch: In Section 3.2, at the first bullet in the list, it says: "an application uses XPointers in other context than as a URI-reference's fragment identifier(...)".

This issue has no corresponding entry in the XPointer issues list.

Resolution: Accepted, it should read: "an application uses XPointers in other contexts than as a URI-reference's fragment identifier(...)".

Issue (issue-typo-operator):

From Susan Lesch: In section 3.3, the second paragraph reads: "This allows the XPointer [] operator to be used to select from sets of ranges, and allow the first operand in a RangeExpr to return ranges. "

This issue has no corresponding entry in the XPointer issues list.

Resolution: Accepted, it should read: "This allows the XPointer [] operator to be used to select from sets of ranges, and allows the first operand in a RangeExpr to return ranges. "

Issue (issue-typo-xpath):

From Susan Lesch: In section 3.3.4, there are two references to the XPath Proposed Recommendation.

This issue has no corresponding entry in the XPointer issues list.

Resolution: Accepted, these references need to be updated to point to the XPath Recommendation.

Issue (issue-type-axis):

From Susan Lesch: In section B.6, first paragraph, it currently reads: "That is in contrast to id("intro")/child::node() which locates all the nodes, of any type, that are children of the intro node. id("intro")/child::para locates all the element nodes of whose element type (tag name) is para that are direct children of the intro node. "

This issue has no corresponding entry in the XPointer issues list.

Resolution: Accepted, this section should read: "That is in contrast to id("intro")/child::node() which locates all the nodes, of any type, that are children of the intro node. id("intro")/child::para locates all the element nodes whose element type (tag name) is para that are direct children of the intro node. "

Issue (wg-i18n-escaping):

Martin Dürst on behalf of the Internationalization Working Group (members only), raised the following issues about character sets and escaping, in section 2.2 of the XPointer Working Draft.

1. The title should be changed from "character sets" to "character encodings".

   Resolution: Accepted, the Working Group will make the change that Martin suggests.

   This issue relates to XP55 (members only) in the Issues List.

2. The text should be more detailed in section 2.1 and 2.2, in regards to escaping.

   Resolution: Accepted, the editors have been asked to clarify this section, possibly by reusing some wording from the original mail.

   This issue relates to XP35 (members only) in the Issues List.

3. Martin believes the ^ escaping mechanism is unnecessary, and provides reasons for why he believes it is not.

   Resolution: Rejected, The WG was not able to convince itself that the ^ escaping was not necessary, and at a minimum we would have to specify the rules around escaping of parentheses in more detail. Therefore the group decided to leave the spec as-is.

   This issue relates to XP36 (members only) in the Issues List.

4. Martin believes that we should clarify that the UTF-8 encoding is not necessary for URI-references, but rather, for XPointer itself.

   Resolution: Accepted, the editors will add a clarifying note on this topic, in the vein of what Martin suggests.

   This issue relates to XP56 (members only) in the Issues List.

5. Martin believes that the specification should clarify certain distinctions about illegal characters in URI-references.

   Resolution: Accepted, a clarification about this issue will be written that describes the use of illegal character use in URIs.

   This issue relates to XP57 (members only) in the Issues List.

6. Martin believes that the second validity constraint in this section is unnecessary. This validity constraint declares that not all legal XPath expressions may be used when escaping.

   Resolution: Accepted, the editors will make the changes Martin suggests.

   This issue relates to XP58 (members only) in the Issues List.

7. Martin believes that this section must directly reference the Unicode and UTF-8 specifications.

   Resolution: Accepted, the editors should add the references to Unicode 3.0 and RFC 2379, respectively.

   This issue relates to XP59 (members only) in the Issues List.

Issue (wg-i18n-pointsrange):

Martin Dürst on behalf of the Internationalization Working Group (members only) raised the following issues about points and ranges, defined in section 3.3 of the XPointer Working Draft.

1. Points and ranges, in accordance with DOM2 and with our Character Model (see the Character Model Working Draft), use 0-based indexing. However, as far as we understand, it seems impossible to access points or ranges based on these indices.

   Resolution: Accepted, the Working Group will include a Note on this subject.

   This issue relates to XP37 (members only) in the Issues List.

2. Points and Ranges correspond, to DOM's "position" and "range". However, DOM's position and range are based on UTF-16 units. XPointer on the other hand works on UCS characters, as is clear from Section 3.6 of the XPath Recommendation.

   Resolution: Accepted, Clarifying text should be put in the same Note described above. This text should say something to the effect that XPointer deviates from the DOM in this regard.

   This issue relates to XP37 (members only) in the Issues List.

Issue (wg-i18n-conformance):

Martin Dürst on behalf of the Internationalization Working Group (members only) raised the following issue about the introduction of the XPointer Working Draft: In regards to robustness requirements 'must attempt to be internationalized' apparently isn't strong enough for the Internationalization Working Group. They would like the Working Group to state that internationalization is a requirement in implementing XPointer.

Resolution: Partly accepted, the Working Group believes that it would be inappropriate to force conformance to internationalization beyond the levels already provided by the XML specification. In fact, since the XML specifications XPointer is based on are already internationalized, the reference to internationalization should be removed from our specification.

This issue relates to XP60 (members only) in the Issues List.

Issue (wg-i18n-childseq):

Martin Dürst on behalf of the Internationalization Working Group (members only) raised the following issue about section 2.1.3 of the XPointer Working Draft: The Internationalization Working Group regards the child sequencing methodology described as "unstable". However, no explanation of the instability is given.

Resolution: Rejected, The Working Group plans to let the text sit as is, as the methodology does not appear unstable, at least not anymore unstable that any other XPointer construct is in regards to editing.

This issue relates to XP38 (members only) in the Issues List.

Issue (wg-i18n-stringrange):

Martin Dürst on behalf of the Internationalization Working Group (members only) raised the following issue about section 3.5 of the XPointer Working Draft: The Internationalization Working Group believes that the white space handling in string-ranges is inadequate, insofar as this is used to deal with 'pretty printing' in the source or in XPointers (as opposed to catching spurious double spaces...). This is deemed inappropriate because it does not cover languages that are written without spaces, such as Thai, Chinese, and Japanese.

Resolution: Accepted, string normalization is dropped. Paul Grosso sent a very clear mail (members only) on the subject and suggesting four possible actions. The editors are instructed to remove the section on normalization, add note how XML processors have to normalize end of line characters.

This issue relates to XP40 (members only) in the Issues List.

Issue (wg-i18n-normalization):

Martin Dürst on behalf of the Internationalization Working Group (members only) raised the following issue about section 3.5 of the XPointer Working Draft: The Internationalization Working Group believes that there should be some comment about matching and normalization in this section. They want the document to claim that only codepoint-by-codepoint matching is done, and that both source and XPointer are assumed to be normalized, and that for things such as case-folding, appropriate functions in XPath should be used.

Resolution: Accepted, the editors have been directed to add the suggested comment.

This issue relates to XP39 (members only) in the Issues List.

Issue (member-oracle-ranges):

Jim Trezzo of Oracle raised the issue of ranges, as have a number of other parties. In brief, the debate has raged over the inclusion of the ability to define a range of text that may or may not be constricted to a document node. The concern has largely been placed on the usefulness of such a feature, compared with the difficulty of maintaining any clear understanding of a range after a document transformation (such as might be performed by an XSL stylesheet).

Others have raised this issue, including the XSL Working Group (members only), Paul Grosso of Arbortext, Jonathan Marsh of Microsoft, and Rick Jelliffe of Academia Sinica.

Resolution: Rejected, the Working Group debated this topic fiercely, and finally decided in favor of keeping ranges in the specification. The minority (members only) opinions and majority (members only) opinions are available online to W3C members.

This issue relates to XP43 (members only) in the Issues List. Minority and majority (members only) opinions reflecting the Working Group's concensus are available.

Issue (wg-xsl-xpointermapping):

The XSL Working Group (members only) and Oracle Corporation believes there is an interoperability issue with reverse-mapping XPointers to documents transformed via XSLT.

Resolution: Rejected, the Working Group responds that XPointer addresses within a given Infoset. XPointer has no notion of input or result set. This issue is out of scope for the XPointer specification.

This issue relates to XP44 (members only) in the Issues List.

Issue (wg-smil-nosupport):

Aaron Cohen, speaking on behalf of the SYMM Working Group (members only), submitted an explanation of why SMIL Boston will not be supporting XPointer. This explanation can be found at the www-xml-linking-comments archive, open to the public.

Resolution: Accepted, since the SYMM WG is not objecting to XPointer, there is no further action to be taken in regards to the specification. However, synchronizing with future versions of SMIL should certainly be considered for the next versions of XPointer.

In regards to the question asked in Aaron Cohen's comments, "Is it legal to subset XPointer?",

Resolution: Rejected, the Working Group's answer is that it is not.

This issue relates to XP42 (members only) in the Issues List.

Issue (techerrors-timbl-multiple):

Tim Berners-Lee is concerned that that XPath allows returning multiple values, and XPointer doesn't constraint itself to allow to return multiple (non-consecutive) nodes, or multiple points/ranges. This complicate handling and may be hard to get implemented and linked to user interfaces.

Note that the I18N Working Group considered that a good feature.

Resolution: Rejected, the Working Group believes this to be a feature, and has decided to keep it. This will be tested during CR phase.

This issue relates to XP46 (members only) in the Issues List.

Issue (techerrors-mdyck-preceding):

Michael Dyck raises the issue that, in section B.3 we declare that the preceding relative axes: "Locates nodes that begin before (preceding) the entire context node. The list is in reverse document order: the node closest to the context node first, root() last. Ancestors are included." This is in direct conflict with XPath, which states that explicitly excludes ancestors from the preceding axis.

Resolution: Accepted, the specification needs to be modified to correct this error. We ought to drop the last sentence in the paragraph discussing ancestors.

This issue relates to XP61 (members only) in the Issues List.

Issue (techerrors-duerst-schemes):

Martin Dürst notes that, in section 2.3 of the specification, we don't appear to address the problem of management and reservation of scheme names. Specifically, we don't appear to address the concept of namespace collision between schemes.

Resolution: Accepted, all other sheme name than 'xpointer' are forbidden until we find a repository accepting to do scheme registration and maintain the list. W3C will not do it.

This issue relates to XP47 (members only) in the Issues List.

Issue (techerrors-duerst-node):

Martin Dürst notes that, in the definition of a node, we are in conflict with the Infoset, which does not include the concept of text nodes. The DOM does define text nodes, however.

Resolution: Rejected, XPointer is compliant with the XPath notion of text nodes.

This issue relates to XP62 (members only) in the Issues List.

Issue (techerrors-duerst-axisusage):

Martin Dürst notes that, in section B.6, the following text is inaccurate: "Perhaps the most important of these allows the axis identifier and parentheses to be omitted from a Step".

Resolution: Accepted, Martin is correct. The text should read: "Perhaps the most important of these allows the axis-name and double-colon to be omitted from a Step". This change should, preferably, reference the axis-name production. We should not mention the parentheses at all.

This issue relates to XP63 (members only) in the Issues List.

Issue (techerrors-duerst-namespace):

Martin Dürst states that the integration of namespaces and XPointer needs to be improved. He suggests an alternate scheme based on uri-name()="http://www.foo.com/bar:y".

Resolution: Rejected. While Martin may be correct, this function is inherited from XPath, and if it needs to be fixed, then it needs to be fixed there. The XML Linking Working Group will provide feedback to get a better scheme in future version of XPath.

This issue relates to XP49 (members only) in the Issues List.

Issue (techerrors-harold-root):

Elliotte Rusty Harold notes that the current Working Draft still mentions the root() function, which no longer exists.

Resolution: Accepted, root() function doesn't exist anymore. The editors are directed to replace root() by references to the "/" construct.

This issue relates to XP52 (members only) in the Issues List.

Issue (techerrors-hanson-nodepoint):

Robert Hanson, via Elliotte Rusty Harold, notes that characters in a node who have child nodes are neither node-points nor character-points. They seem to be currently undefined.

Resolution: Rejected, Nodes are not elements, therefore the situation described above cannot occur.

This issue relates to XP51 (members only) in the Issues List.

Issue (features-marsh-whitespace):

Jonathan Marsh suggests that XPointer ought to allow whitespace in schemes, in the manner that #xpointer(...) xpointer(...) is legal, since whitespaces are allowed between the parentheses.

Resolution: Accepted, the editors are instructed to add a note supporting this position, with the caveat that the whitespace will need to be escaped in a URI.

This issue relates to XP48 (members only) in the Issues List.

Issue (features-marsh-null):

Jonathan Marsh suggests that XPointer requires a null pointer, like the kind used to advantage in many database applications. He suggests that this could be accomplished by introducing a new fragment scheme null, which accepts no arguments.

Resolution: Rejected, the Working Group does not see the need for this construct in the current specification, and acknowledges that it could be added later as a new fragment scheme.

This issue relates to XP50 (members only) in the Issues List.

Issue (features-veillard-alternativeranges):

Daniel Veillard and Steven DeRose have recently suggested that an alternative syntax for ranges might be beneficial. It is described in a discussion beginning on the XML Linking Working Group's mailing list (members only).

Resolution: Accepted, There seems to be interest in simplifying the range syntax. The Working Group agrees to change the range syntax based on the "to" construct to be based on a "rangeto" function, instead.

This issue relates to XP54 (members only) in the Issues List.

Issue (features-masinter-ipv6):

Larry Masinter proposes (as a result of work in representing IPv6 addresses in URLs) to move the characters "[" and "]" into the reserved set.

Resolution: Rejected, the Working Group has decided to keep use of "[" and "]" as they are actually used in XPath. It is thus out of scope of XPointer to address this issues. It is noted that those caracter will need to be escaped even with current version of the URI specification.

This issue relates to XP41 (members only) in the Issues List.