Bug 18861 - [XSLT 3.0] predicates in patterns
[XSLT 3.0] predicates in patterns
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0
Last Call drafts
PC All
: P2 normal
: ---
Assigned To: Michael Kay
Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
  Show dependency treegraph
Reported: 2012-09-12 20:40 UTC by Michael Kay
Modified: 2013-08-11 21:39 UTC (History)
1 user (show)

See Also:

Suggested improvements for the pattern syntax (1.60 KB, text/plain)
2013-07-25 15:31 UTC, Abel Braaksma

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kay 2012-09-12 20:40:57 UTC
The current XSLT 3.0 pattern syntax appears to allow






  but not

Comment 1 Michael Kay 2012-09-12 21:04:45 UTC
Also, the pattern syntax appears to allow


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].
Comment 2 Michael Kay 2012-09-17 15:25:25 UTC
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.
Comment 3 Michael Kay 2012-09-17 15:39:38 UTC
I believe the following revised grammar fixes the problems:

[1] Pattern       ::=       PatternTerm ( ('|' | 'union') PatternTerm )*

[2] PatternTerm       ::=       PathPattern ( ('intersect' | 'except') PathPattern )*

[3]      PathPattern       ::=      
| '/' 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}
Comment 4 Michael Kay 2013-02-12 09:19:58 UTC
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.
Comment 5 Michael Kay 2013-03-28 18:39:17 UTC
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.
Comment 6 Abel Braaksma 2013-07-25 15:31:25 UTC
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).
Comment 7 Abel Braaksma 2013-07-27 12:36:02 UTC
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.
Comment 8 Michael Kay 2013-07-31 15:43:14 UTC
The original issue is now resolved. There are other issues that have emerged with pattern syntax, but these will be addressed elsewhere.