This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In implementing erratum XQ.E34, concerning disambiguation of leading lone slash, I have belatedly realized that the agreed wording has an unfortunate effect on the expressions / + 5 / - 5 These expressions were unambiguous and had a clear meaning in XPath 1.0. The "+" or "-" is taken as a binary infix operator. The expressions weren't particularly useful, except in the case of a document containing a single text node: but such documents aren't that unusual in XSLT 1.0 stylesheets. The effect of the erratum is to change the way these expressions are parsed, so that the "+" or "-" is taken as a unary operator; the value of the expression is now +5 or -5, irrespective of the content of the context document. Although these expressions are likely to be rare, it seems irresponsible to change the meaning of existing user code, especially when the old meaning is more intuitive than the new. I would therefore propose changing the agreed erratum text. Instead of "if the token immediately following a slash can form the start of a RelativePathExpr, then the slash must be the beginning of a PathExpr, not the entirety of it.", we should say "if the token immediately following a slash can form the start of a RelativePathExpr, and is not the token "+" or "-", then the slash must be the beginning of a PathExpr, not the entirety of it."
I've looked more carefully at the grammar, and it seems this is not a problem, because unary plus and unary minus cannot appear at the start of a RelativePathExpr. An expression that isallowed at the start of a RelativePathExpr must be either an AxisStep or a PrimaryExpr. AxisStep includes various forms of wildcard as well as ".." and "@xx". PrimaryExpr includes literals, function calls, parenthesized expressions, ".", variable references, ordered{} and unordered{}, and direct and computed node constructors. It doesn't include unary plus or minus, conditional expressions, FLOWR expressions, validate expressions, pragmas, or various other things that could be parsed without ambiguity in such a context if we chose to allow them. It seems pretty arbitrary what's allowed and what isn't, and I made the mistake of assuming that any unary operator would have higher precedence than an infix binary operator, but it doesn't, so this problem doesn't exist. I'm closing it as INVALID.