This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 18861 - [XSLT 3.0] predicates in patterns
Summary: [XSLT 3.0] predicates in patterns
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-12 20:40 UTC by Michael Kay
Modified: 2013-08-11 21:39 UTC (History)
1 user (show)

See Also:


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

Description Michael Kay 2012-09-12 20:40:57 UTC
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"
Comment 1 Michael Kay 2012-09-12 21:04:45 UTC
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].
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?
| '//' 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.