Copyright © 2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document details the responses made by the XML Linking Working Group to issues raised during the Candidate Recommendation (beginning 7 June 1999 and ending xx 1999) review of XPointer . Comments were provided by XML Linking Working Group members, other W3C Working Groups, and the public via the www-xml-linking-comments@w3.org (archive) mailing list.
This document of the W3C's XML Linking Working Group describes the disposition of comment as of $Date: 2000/12/18 09:59:34 $ on XPointer Candidate Recommendation. It may be updated, replaced or rendered obsolete by other W3C documents at any time.
For background on this work, please see the XML Activity Statement.
It is possible to consult the disposition of Last Call comments
1 Introduction
2 Editorial Comments
2.1 Spelling Errors and Other Typos
2.2 Requests From Other Working Groups and Member
Companies
2.3 Technical Errors
2.4 Additional Features
This document describes the disposition of comments in relation to the XPointer Candidate Recommendation. The comments have been categorized: editorial comments (consisting of spelling and grammatical errors), requests from other Working Groups and Member Companies, obvious technical errors in the current specification, and finally, additions to the feature set of XPointer. Each issue is described by the name and contact information of the commentator, a description of the issue, and either the resolution or the reason that the issue was not resolved.
Issues that were based on expanding definitions, clarifying material, or otherwise based on subjective interpretation of the specification's quality have been omitted from this document for the sake of brevity. It may be assumed that such issues were taken into account by the Working Group, and that it is the Working Group's opinion that the current text is sufficient.
Finally, basic issues in terms of spelling and grammatical errors that have been resolved since being raised are not included in this document, for the sake of brevity.
From Michael Kay :
Resolution (Member Only): Accepted, Editorial changes were agreed upon, and unique() was decided to be dropped from XPointer
This issue relates to XP72 in the Issues List.
From Susan Lesch :
Resolution (Member Only): Accepted, Editorial changes were agreed upon
This issue relates to XP75 in the Issues List.
From Jeffrey Bacon :
Resolution (Member Only): Accepted, Editorial changes were agreed upon
This issue relates to XP77 in the Issues List.
From Elliotte Rusty Harold :
XPointer pointing into a non-final October 1999 draft of XPath,
Resolution (Member Only): Accepted, Editorial changes were agreed upon
This issue relates to XP78 in the Issues List.
From Elliotte Rusty Harold :
Declaration errors for functions start-point() and end-point()
Resolution (Member Only): Accepted, Editorial changes were agreed upon
This issue relates to XP79 in the Issues List.
From Daniel Veillard :
Resolution (Member Only): Accepted, Editorial changes were agreed upon
This issue relates to XP82 in the Issues List.
From Jose Kahan :
Finding the conformance definition is hard
Resolution (Member Only): Accepted, a sentence saying there is no optional part and compliance can only be claimed by full implementation will be added in this section.
This issue relates to XP83 in the Issues List.
From Michael Dyck asked to clarify the end of the paragraph on covering ranges:
5.3.3 Covering Ranges for All Location Types
"This definition ensures that for a range location, [various axes] do not
intersect and that they together contain all locations in the document
(other than attribute, namespace, and range locations)."
I think this paragraph is misplaced. I don't see how the definition of
"covering range" has anything to do with establishing how a range's
axes partition the document. In fact, the only use I see of the term
"covering range" is in the definition of the "range" function. Maybe
the content of this section should be moved there.
Resolution (Member Only): Accepted, this paragraph was not adequate, the editors will keep the definition but remove the final paragraph of the final bullet point.
This issue relates to XP93 in the Issues List.
From Michael Dyck raised another problem about the paragraph on covering ranges:
5.3.3 Covering Ranges for All Location Types
And I think you'll have to add point locations to the "other than"
list. As far as I can tell, no axis contains a point location except
for the self axis of a point (or range, see above).
Resolution (Member Only): Accepted, the resolution of MD8 also covers this issue.
This issue relates to XP94 in the Issues List.
From Michael Dyck :
5.4.2 string-range() Function
prototype:
Delete space between "location-set" and comma.
Resolution (Member Only): Accepted.
This issue relates to XP96 in the Issues List.
From Michael Dyck asked to clarify the string-range() function definition:
5.4.2 string-range() Function
the resulting range:
What happens if third and/or fourth arguments specify positions that
lie outside the string-value of the location?
Resolution (Member Only): Accepted, this will be defined more clearly. When the position is outside the document range it generates an XPointer scheme part error.
This issue relates to XP97 in the Issues List.
From Michael Dyck asked to clarify another aspect of the string-range() function definition:
5.4.2 string-range() Function
"indicates a string that is beyond":
You mean wholly beyond, or even just partly beyond?
Resolution (Member Only): Accepted, the new draft defines it more clearly and "the third or fourth argument indicates a string" will be substitued by "the third or fourth argument indicates a position".
This issue relates to XP98 in the Issues List.
Paul Grosso on behalf of the XML Core Working Group (members only), raised the following issue:
Some documents may be delivered as XML but not have Infosets:
Those documents may be considered of Mime Type XML, but since they don't have Infoset (or rather an XPath "data model") it seems one cannot use XPointer for those resources.
The mail present 2 well formed external parsed entities but without a single root element, and ask for clarification about using XPointer if this is allowed.
Resolution (Member Only): XPointer applies only to document for which an Infoset or an XPath data model can be built.
This issue was continued as Issue(parsed-entities) where the possibility of building an Infoset for well balanced external parsed entities was submitted to the XML Core WG.
This issue relates to XP65 in the Issues List.
Paul Grosso on behalf of the XML Core Working Group (members only), raised the following issue:
How does the fact that "xpointer points into a resource whose mime type is XML" reconcile with the idea that xpointer points into an Infoset (or, specifically the "data model" defined by XPath, since XPath preceded the existence of an official infoset)?
Resolution (Member Only): First as pointed in Issue(no-infoset), XPointer applies only to document for which an Infoset or an XPath data model can be built. Second the editor suggested a number of change to clarify the issue. XPointer will keep a reference to XPath and the Infoset.
This issue was continued as Issue(parsed-entities) where the possibility of building an Infoset for well balanced external parsed entities was submitted to the XML Core WG.
This issue relates to XP73 in the Issues List.
John Boyer on behalf of the XML Signature Working Group, raised the following issue:
What should here() return when it appears as follows:
<e> h<!-- yikes -->ere()/...</e>
I would like to add to that by asking, what should happen below:
<e>here()/... | <!-- yikes times two -->
here()/...</e>
In practice XPointer and XML DSig versions of here() had diverged again (both here() definition were synchronized before CR) .
Resolution (Member Only): Accepted, this generated a consequent discussion (members only) which was solved by a vote. The suggested solution of returning the parent element was selected. XPointer and XML DSig versions of here() should be the same.
This issue relates to XP81 in the Issues List.
The joint XSL/XML Linking Task Force, asked for a subset of XPointer to be created which would eliminate ranges:
We have observed that arbitrary ranges introduce some problematic situations for styling. In any styling technology whose data model granularity is coarser than the Infoset (which includes both XSLT and CSS, for example), XPointer ranges might identify material that is not "compliantly" expressible in styling terms. This problem is most acute in the case of embedding, and, more generally, in any case where the presentation context is equal to the ending resource. There is also the tricky case of string ranges that begin or end in the middle of a presented multiple-character glyph.[9] The XSL-affiliated members of the task force are working with that group on the data model issue and are recommending some extension functions to tide developers over. We have also recommended some strategies for "sloppy" application of link behavior in cases where this is acceptable to all applications and users involved.[10] However, for the sake of all styling technologies with the same problem (some of which may not be able to be upgraded in the near future), we recommend that a subset of XPointer be created that eliminates ranges (and possibly string ranges), in order to offer a version of XPointer whose data model has a better match with these technologies. In this way, applications could choose to claim compliance to this subset or require use of it as appropriate. This subset could perhaps take the form of a new scheme, such as #xptr-basic(...). [9] http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#range-ligs [10] http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#spec-range-display
Resolution (Member Only): Rejected, this generated a consequent discussion (members only). A large portion of the group disagreed with the prospect of having XPointer implementation without any range support or the possibility of multiple conformance levels for a specification defining the fragment identifier of a resource type. A clear majority prefered the status-quo.
This issue relates to XP80 in the Issues List.
From Michael Kay :
The syntax of ChildSeq suggests that XPointer is constrained to operate on well-formed XML documents (those with a single top-level element), in contrast to XPath which also operates on well-balanced XML fragments.
This is also related to Issue(no-infoset)
Resolution (Member Only): Accepted, the Working Group was tempted to follow XSLT in addressing into well balanced document. This resulted in a question asked to the XML Core WG to extend the Infoset capabilities to external parsed entities. This won't be added to the Infoset 1.0, however support to address top elements in fragments has been added to XPointer.
This issue relates to XP66 in the Issues List.
Issue (flexible-initialization):
From Michael Kay :
Application (for example XSLT) reuse of XPointer will be made difficult due to our strict definition of the context initialization:
- Section 5.2, bullets 4 and 5. This appears to ban applications from defining a way of binding variables and functions and using them in an XPointer, which seems unnecessarily heavy-handed, for example it would make it difficult to extend XSLT to use XPointer. Wouldn't it be better to say that the set of variable bindings is determined by the application, and is empty by default?
- Section 5.2, bullet 6. This probably ought to say something about the default namespace, rather than leaving it implicit. Again, it seems heavy-handed to prevent namespaces being bound in some application-defined way, for example in an API that uses XPointer syntax this would make it very difficult to refer to namespace-qualified names.
Resolution (Member Only): Rejected, the first suggestion was rejected on ground of interoperability. Concerning the problem of addressing namespace-qualified names is well know and should be addressed at the XPath level.
This issue relates to XP67 in the Issues List.
From Michael Kay :
Points object definition lacks a couple of informations:
- The definition of the axes of a point location should include a definition of the parent and self axes. (It perhaps needs to be stated that the concept of an axis is *not* being generalized to return any location, it still always returns a node-set).
- Section 5.3.2, second paragraph. The concept of two points being "equal" has not been defined. (It needs to be distinguished from the XPath "=" operator).
Resolution (Member Only): Accepted, this generated a long discussion, especially for point equality when one of the nodes may be at the origin or end of a text string. So there was no consensus to disallow case where points may be differents but undistinguishable at the rendering level. The editors are however instructed to make the distincion clear in the specification.
This issue relates to XP68 in the Issues List.
From Michael Kay asking for clarification on the impact of range-to() on XPath syntax, and suggesting a different syntax :
Section 5.4.1, Note. This extension to XPath syntax needs much more formal treatment. Exactly how is the BNF modified? Which functions are allowed after a "/"? What are the semantics? I'm worried that this extension is "jumping the gun" in terms of how XPath evolves.
I think that this kind of requirement, along with many others, would be much better met by allowing a function to take an expression (or function) as an argument, so it could be written say range-to(id("chap1"), function: following::REVEND(1]). (This concept is needed to do things such as universal and existential quantifiers, summing an arbitrary expression, etc).
Resolution (Member Only): Accepted, the issue was discussed with Michael Key and while the initial suggested syntax was not selected, an agreed upon modification to production 4 of XPath will be provided as well as a couple of other changes to the specification.
This issue relates to XP69 in the Issues List.
From Michael Kay asking for clarification in the description of error handling :
Resolution (Member Only): Accepted, agreed to change the errors to be sub-resource errors whose semantic is clearly defined.
This issue relates to XP70 in the Issues List.
From Michael Kay What happen if the XPath expression doesn't evaluate to a Node Set ?:
I didn't see anything in the XPointer spec that says the XPath expression has to evaluate to a node-set. Since 2+2 is a valid XPath expression, it seems that XPointer(2+2) is a syntactically valid XPointer, though presumably it will always fail as "a scheme that does not locate any subresource present in the resource". However, the rule that the expression must return a node-set could be stated more explicitly; and in particular, the syntax of an XPointer could refer to an XPath UnionExpr rather than an XPath Expr, since an Expr that is not a UnionExpr will never return a node-set.
In fact the rules could be more restrictive than this. As a precedent, the XSLT syntax for Patterns describes a subset of XPath syntax that will always return a node-set. This subset is probably more restrictive than the subset that would be appropriate for XPointer, for example because it only allows use of the child and attribute axes, but the same idea could be applied.
Resolution (Member Only): Accepted, the specification will be augmented by prose exlaining that returning anything other than a location set is a sub-resource error.
This issue relates to XP71 in the Issues List.
From Michael Dyck asked to remove a restriction:
3.5 Classes of XPointer Errors
"syntax error":
"and applications must not attempt to evaluate it as an XPointer"
This restriction conflicts with the last sentence of the section:
"This specification does not constrain how
applications deal with these errors."
I'd remove the restriction.
(If you think it should stay, then why isn't there a similar
restriction for resource errors? Why is there no restriction on the
location-set yielded by an XPointer with a sub-resource error?)
In any event, discussion of how applications deal with syntax errors
should not be within the *definition* of "syntax error".
Resolution (Member Only): Accepted in part, the error conformance definitions have been clarified. The xpointer expression is evaluated left to right, if a sub-resource error is found when evaluating a scheme then the processing should be done on next scheme, but if it is a syntax error the evaluation stops.
This issue relates to XP86 in the Issues List.
From Michael Dyck asked some clarification about the XML escaping of embedded URI-References with XPointer:
4.1.2 XML Escaping
"Note that if XML-based languages define elements or attributes containing
URI references (such as XLink's href attribute shown above), the relevant
element content or attribute values also require the processing defined in
4.1.1 URI Reference Encoding and Escaping."
So shouldn't you complete the example by performing this processing?
You could put the final result in a third box, so that the result of
just the XML-escaping is still clear from the first two boxes.
You might also note that if the URI-escaping were performed first, it
would (among other things) change "<" into "%3C", which would (1) make
XML-escaping unnecessary, and (2) result in a slightly different
fragment identifier for the same XPointer.
Resolution (Member Only): Accepted, This generated a large thread involving Martin Duerst. This is a 3 steps processing, and the editors will add the description of this processing in a new 4.1.1 section.
This issue relates to XP87 in the Issues List.
From Michael Dyck asked to change the XPointer BNF part to fully express the escaping syntax:
4.2 Forms of XPointer
StringWithBalancedParens:
The EBNF does not admit escaped (unbalanced) parentheses. Yes, the
validity constraint allows them, but I think it's unusual for a VC to
be more permissive than the EBNF. Normally VCs are more restrictive.
In the EBNF, you could change "[^()]*" to
( [^()] | '^' [()] )*
which you might want to split off into its own production.
(This, like the original, allows arbitrary occurrences of circumflex.
You could disallow it in the EBNF, but only by having two different
uses of circumflex in the same expression. In the VC, you might want to
say "Any other occurrence of circumflex results in a syntax error.")
Resolution (Member Only): Rejected, there is a balance between having a very complex BNF or using some prose to further refine a simplified BNF. The Working Group prefered to keep the BNF as it is, but asking the editors to add a sentence about the extra syntax rules not expressed by the BNF. Gavin Nicol objected.
This issue relates to XP88 in the Issues List.
From Michael Dyck raised an issue with the definition of Point locations:
5.3.1 Definition of Point Location
"the location preceding any individual character ... in an XML document":
Might as well say "preceding or following", as with nodes.
Actually, a point can't represent *any* such location, in particular
it can't represent locations between markup characters.
Resolution (Member Only): Accepted, this can be cleared simply by adding "of the data set constructed from" before "of an XML document".
This issue relates to XP89 in the Issues List.
From Michael Dyck raised another issue with the definition of Point locations:
5.3.1 Definition of Point Location
What about the `parent' axis? Does a point location have a parent?
What about the `preceding' and `following' axes?
What about the `self' axis? One guesses that it would contain just
the point itself.
Resolution (Member Only): Accepted, the full definition of the axis of a point will be provided.
This issue relates to XP90 in the Issues List.
From Michael Dyck asked how ranges would interract with entities:
5.3.2 Definition of Range Location
Can the start and end points be in different entities?
Resolution (Member Only): Acknoledged, the data model is defined in XPath, entities are replaced before XPath/XPointer processing, yes this is possible.
This issue relates to XP91 in the Issues List.
From Michael Dyck asked to clarify the axis definition for a range location:
5.3.2 Definition of Range Location
"The axes of a range location are the axes of its start point."
So if the `self' axis of a point contains just the point,
then the `self' axis of a range contains just its start point,
which is probably not what people would expect.
Some of the other axes (e.g., `parent' and `following') are also a bit
odd under this definition. Not that that's wrong, but it might be
worth a note saying, "yes this is intentional".
Resolution (Member Only): Accepted, the definition as given is kept, but the editors will add an example to clarify taht it is the actual intent.
This issue relates to XP92 in the Issues List.
From Michael Dyck asked to change the signature of the range-to function:
5.4.1 range-to Function
prototype:
Change "expression" to "location". (Every argument is an expression.
The prototype must give the expected type of the value of the
argument.)
Resolution (Member Only): Accepted, the change will be made in the next version of the draft.
This issue relates to XP95 in the Issues List.
From Michael Dyck asked to clarify range-inside() for point locations:
5.4.3 Additional Range-Related Functions
range-inside:
The definition seems to ignore the possibility that x might be a point
location: a point can't be a container.
Resolution (Member Only): Accepted, the new version will define range-inside for a point as being the point itself.
This issue relates to XP99 in the Issues List.
From Michael Dyck asked change the error handling of end-point():
5.4.3 Additional Range-Related Functions
"the function must signal a syntax error":
Change to "no point is added to the resulting location-set".
Resolution (Member Only): Acknoledgeded/Rejected, the start-point() function definition was fixed to address a similar case but end-point() was forgotten. The editors will fix end-point() in the same way: the XPointer part in which the function appears fails. This is not a syntax error but the case is still handled as an error.
This issue relates to XP100 in the Issues List.
From Michael Dyck asked to change here() error handling:
5.4.4 here Function
"syntax error":
I think "resource error" would make more sense.
Resolution (Member Only): Accepted, the definition will be updated to state that the XPointer part in which the function appears fails.
This issue relates to XP101 in the Issues List.
From Lance Otis suggested some additional functions :
We would like to add some flexibility to the XPointer spec for document search.
Can the XPointer spec be changed to include functions such as similar-to(), find-by-concept(), and find-by-query() with the appropriate arguments?
Resolution (Member Only): Declined, adding new features at CR stage is a hard decision. Those are searching related and rather difficult to specify and implement. It seems more useful to reference output from the XML Query WG when available, possibly by augmenting future versions of XPointer to reuse those.
This issue relates to XP76 in the Issues List.