29655 2016-05-20 20:55:33 +0000 [XP31] Ambiguous parse for /[x] 2016-05-23 11:59:28 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XPath 3.1 Candidate Recommendation PC All RESOLVED INVALID P2 normal --- 1 mike jonathan.robie jmdyck josh.spiegel public-qt-comments oldest_to_newest 126471 0 mike 2016-05-20 20:55:33 +0000 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. 126472 1 josh.spiegel 2016-05-20 22:37:30 +0000 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? 126473 2 jmdyck 2016-05-21 13:48:06 +0000 (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]. 126481 3 mike 2016-05-23 11:59:28 +0000 Closed as invalid. I was misdiagnosing the root cause of a problem reported by a user.