This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The current XSLT 3.0 pattern syntax appears to allow match="$x" and match="$x/abc" and match="$x[xyz]" but not match="$x[xyz]/abc"
Also, the pattern syntax appears to allow /[x] which is not a legal XPath expression. The semantics rely on all patterns (after expansion of "~") being legal XPath expressions. In XPath expressions, this has to be written as (/)[x].
The statements in comments 0 and 1 don't seem quite correct. It seems that the grammar allows a predicate after a RootedPattern (such as "/" or "$x") only if the rooted pattern is in parentheses. So $x[xyz] is not allowed, but ($x)[xyz] is.
I believe the following revised grammar fixes the problems: [1] Pattern ::= PatternTerm ( ('|' | 'union') PatternTerm )* [2] PatternTerm ::= PathPattern ( ('intersect' | 'except') PathPattern )* [3] PathPattern ::= RelativePathPattern | '/' RelativePathPattern? | '//' RelativePathPattern | StartPattern (('/'|'//') RelativePathPattern)? [4] RelativePathPattern ::= StepPattern (("/" | "//") StepPattern)* [5] StepPattern ::= PatternAxis? NodeTest{XP3} PredicateList{XP30} [6] PatternAxis ::= ("child" "::") | ("descendant" "::") | ("attribute" "::") | ("self" "::") | ("descendant-or-self" "::") | ("following-sibling" "::") | ("following" "::") | ("namespace" "::") | "@" [7] StartPattern ::= PrimaryPattern PredicateList{XP30} [8] PrimaryPattern ::= VarRef{XP30} | ParenthesizedPattern | FunctionCall | TypePattern [9] ParenthesizedPattern ::= "(" Pattern ")" [10] FunctionCall ::= DocCall | IdCall | ElementWithIdCall | KeyCall [11] DocCall ::= 'doc' '(' ArgValue ')' [12] IdCall ::= 'id' '(' ArgValue (',' ArgValue )? ')' [13] ElementWithIdCall ::= 'element-with-id' '(' ArgValue (',' ArgValue )? ')' [14] KeyCall ::= 'key' '(' ArgValue ',' ArgValue (',' ArgValue )? ')' [15] ArgValue ::= Literal{XP30} | VarRef{XP30} [16] TypePattern ::= '~' ItemType{XP30}
We worked on the grammar today and sketched out a revised grammar by hacking away unwanted parts of the XPath grammar. This is in Feb2013/0019.html in the XSL WG archives. This needs further review offline before we are comfortable with it.
The current status is that the grammar has been written up in the spec and appears satisfactory. Michael Dyck has pointed out that there's a technical ambiguity in the way it's constructed, because xx() can be both a function call and a kind-test; we probably have to disambiguate that by listing the allowed function names in the grammar rather than leaving it to an extra-grammatical rule.
Created attachment 1381 [details] Suggested improvements for the pattern syntax Here's a suggestion based on the remarks above to to keep the limitation on root functions in the pattern syntax. I've also renamed FunctionCallP, because it implies that we have replaced FunctionCall with FunctionCallP, which we haven't, in other places, FunctionCall is still allowed. While none of this is a syntactical ambiguity, perhaps you might consider this alternative syntax as an improvement. See attachment (the comment section makes the syntax almost unreadable).
Around the same time that I added this suggestion, the internal WD was updated and included part of the suggestions that I added here (apparently, I was on the same page as the editor ;) ). From the discussion that followed, I've come to understand that it is not possible to write the EBNF in such a way that it unambiguously allows namespaces or EQNames for the rooted functions. What remains is - should we rename FunctionCallP to something like RootedFunctionCall? - should fn:id() etc be allowed or disallowed, whether in the EBNF or not? The EBNF of XSLT 2.0 disallowed it, but processors seem to silently allow using namespaces. Explicitly disallowing it would mean a backward compatibility issue with current practice, but not with the standard, allowing it would mean a semantic rule on top of the pattern syntax. Doing nothing would keep the status quo.
The original issue is now resolved. There are other issues that have emerged with pattern syntax, but these will be addressed elsewhere.