This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://www.w3.org/TR/xquery/#id-path-expressions describes / as A "/" at the beginning of a path expression is an abbreviation for the initial step fn:root(self::node()) treat as document-node() (this is true even if the "/" is the entire path expression). and // as A "//" at the beginning of a path expression is an abbreviation for the initial steps fn:root(self::node()) treat as document-node()/descendant-or-self::node()/. Note that the expansion of // ends with a trailing / and the expansion of / does not. It would be more correct (I think) if it did end with a trailing slash unless the / was the entire expression. Alternatively (and perhaps better) neither expansion should end with a trailing slash but the text should stress that the expansion is a complete step and in particular a predicate is not allowed to follow. For example fn:root(self::node())[*] is legal and selects root nodes that have a top level element. but fn:root(self::node())/[*] is a syntax error. I believe the intention (and the xquery grammar) is that /[*] is an error rather than selecting a root node that has an element child. One more minor point that I wouldn't have commented on except that I noticed it while pasting in the description of // above, the expanded example ends the sentence and it would help if some indication that the following "." is part of the sentence structure not part of the expression (there is a font change but that's not easy to see on a ".") just inserting a space would probably be enough. David
I don't think that we should change this. Note that rewriting / to (fn:root (self::node()) treat as document-node())/ would yield a syntactically incorrect expression. And I also think that /[expr] should be allowed as expression.
My (first) suggestion was to amend the expansion of a leading / so that it explitly had 2 different expansions, without a trailing / in the case that there is no following step. Currently the text highlights the fact that the expansions are the same, but then if a trailing / is not needed in the expansion of / this reader at least is left asking why one is needed in the expansion of //. The alternative is to not put a trailing / on either and just use the statement that it is a complete step to disallow a following predicate. This is how Xpath 1 dissallowed the syntax .[expr] . (in Xpath1) abreviates a complete step. So far I think all the discussion is editorial: how best to describe the current behaviour And I also think that /[expr] should be allowed as expression. That of course would be a substantive change. I wouldn't disagree with it. As I note above, XPath2 has already made a similar change allowing .[expr] which was previously disallowed. allowing /[expr] but not allowing //[expr] would of course be a convincing argument to explain why the expansion of / does not end with a / but the expansion of // does. David
David, Thanks for your comment. The Query working group has discussed your comment and we agree with you that the expansion of initial "/" should include a trailing "/" unless the initial "/" is the entire path expression. I have edited the XPath/XQuery specification accordingly. We view this as an editorial correction and not as a substantive change to the language. I have also acted on your editorial suggestion to move the sentence-closing period away from the expansion of "//". Since we have implemented your suggestions, I will assume that this issue is satisfactorily resolved unless you reply to the contrary. Best regards, --Don Chamberlin
Thanks David