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 XPath 3.0, the expression /[x] parsed unambiguously, and selected the root node provided it had a child element named x. In XPath 3.1, the expression becomes ambiguous, and the leading-lone-slash rule says it should be parsed as a path expression in which the rhs is an array constructor. This is both incompatible with the XPath 3.0 interpretation, and comparatively useless.
I don't see how /[x] is valid in 3.0 PathExpr => "/" RelativePathExpr => "/" StepExpr => "/" PostFixExpr => "/" PrimaryExpr Predicate It seems like [x] would need to be a PrimaryExpr but I don't think it is. The 3.0 w3c applets don't parse this and neither does my parser. If I am missing something, could you show me the parse tree for this expression in 3.0?
(In reply to Michael Kay from comment #0) > In XPath 3.0, the expression /[x] parsed unambiguously, and selected the > root node provided it had a child element named x. I agree with Josh, I don't think that's ever been the case. In order to parse [x] as a Predicate, it would have to be preceded by a ReverseStep, a ForwardStep, or a PrimaryExpr, but none of those derive /, a PathExpr. To get the semantics you describe, you'd have to write (/)[x].
Closed as invalid. I was misdiagnosing the root cause of a problem reported by a user.