18861 2012-09-12 20:40:57 +0000 [XSLT 3.0] predicates in patterns 2013-08-11 21:39:55 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC All CLOSED FIXED P2 normal --- 1 mike mike abel.braaksma public-qt-comments oldest_to_newest 73723 0 mike 2012-09-12 20:40:57 +0000 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" 73724 1 mike 2012-09-12 21:04:45 +0000 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]. 73997 2 mike 2012-09-17 15:25:25 +0000 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. 73998 3 mike 2012-09-17 15:39:38 +0000 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} 82960 4 mike 2013-02-12 09:19:58 +0000 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. 85117 5 mike 2013-03-28 18:39:17 +0000 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. 91277 6 1381 abel.braaksma 2013-07-25 15:31:25 +0000 Created attachment 1381 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). 91343 7 abel.braaksma 2013-07-27 12:36:02 +0000 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. 91459 8 mike 2013-07-31 15:43:14 +0000 The original issue is now resolved. There are other issues that have emerged with pattern syntax, but these will be addressed elsewhere. 1381 2013-07-25 15:31:25 +0000 2013-07-25 15:31:25 +0000 Suggested improvements for the pattern syntax patternsXSLT.txt text/plain 1643 abel.braaksma WzFdICAgIAlQYXR0ZXJuMzAgCSAgIAkJIAkgOjo9ICBGdW5jdGlvbmFsUGF0dGVybiB8IFVuaW9u RXhwclANClsyXSAgICAJRnVuY3Rpb25hbFBhdHRlcm4gCSAJIDo6PSAgIi4iICJbIiBFeHByICJd Ig0KWzNdICAgIAlVbmlvbkV4cHJQIAkgICAJCSAJIDo6PSAgSW50ZXJzZWN0RXhjZXB0RXhwclAg KCgidW5pb24iIHwgInwiKSBJbnRlcnNlY3RFeGNlcHRFeHByUCkqDQpbNF0gICAgCUludGVyc2Vj dEV4Y2VwdEV4cHJQIAkgOjo9ICBQYXRoRXhwclAgKCgiaW50ZXJzZWN0IiB8ICJleGNlcHQiKSBQ YXRoRXhwclApKg0KWzVdICAgIAlQYXRoRXhwclAgCSAgIAkJIAkgOjo9ICAoIi8iIFJlbGF0aXZl UGF0aEV4cHJQPykNCgkJCQkJCQkJCSAgfCAoIi8vIiBSZWxhdGl2ZVBhdGhFeHByUCkNCgkJCQkJ CQkJCSAgfCBSZWxhdGl2ZVBhdGhFeHByUA0KCQkJCQkJCQkJICB8IFJvb3RlZFBhdGgNCls2XSAg ICAJUm9vdGVkUGF0aCAJICAgCQkgCSA6Oj0gIChWYXJSZWYgfCBSb290ZWRGdW5jdGlvbkNhbGwp IFByZWRpY2F0ZUxpc3QgKCgiLyIgfCAiLy8iKSBSZWxhdGl2ZVBhdGhFeHByUCk/DQpbN10gICAg CVJvb3RlZEZ1bmN0aW9uQ2FsbCAgIAkgOjo9ICBSb290ZWRGdW5jdGlvbk5hbWUgQXJndW1lbnRM aXN0UA0KWzhdICAgIAlBcmd1bWVudExpc3RQIAkgICAgIAkgOjo9ICAiKCIgKEFyZ3VtZW50UCAo IiwiIEFyZ3VtZW50UCkqKT8gIikiDQpbOV0gICAgCUFyZ3VtZW50UCAJICAgICAgICAgCSA6Oj0g IFZhclJlZiB8IExpdGVyYWwNClsxMF0gICAgUmVsYXRpdmVQYXRoRXhwclAgICAgCSA6Oj0gIFN0 ZXBFeHByUCAoKCIvIiB8ICIvLyIpIFN0ZXBFeHByUCkqDQpbMTFdICAgIFN0ZXBFeHByUCAJICAg ICAgICAgCSA6Oj0gIFBvc3RmaXhFeHByUCB8IEF4aXNTdGVwUA0KWzEyXSAgICBQb3N0Zml4RXhw clAgCSAgICAgCSA6Oj0gIFBhcmVudGhlc2l6ZWRFeHByUCBQcmVkaWNhdGVMaXN0DQpbMTNdICAg IFBhcmVudGhlc2l6ZWRFeHByUCAJIAkgOjo9ICAiKCIgVW5pb25FeHByUCAiKSINClsxNF0gICAg QXhpc1N0ZXBQIAkgICAgICAgICAJIDo6PSAgRm9yd2FyZFN0ZXBQIFByZWRpY2F0ZUxpc3QNClsx NV0gICAgRm9yd2FyZFN0ZXBQIAkgICAgIAkgOjo9ICAoRm9yd2FyZEF4aXNQIE5vZGVUZXN0KSB8 IEFiYnJldkZvcndhcmRTdGVwDQpbMTZdICAgIEZvcndhcmRBeGlzUCAJICAgICAgICAgOjo9ICAo ImNoaWxkIiAiOjoiKQ0KCQkJCQkJCQkJICB8ICgiZGVzY2VuZGFudCIgIjo6IikNCgkJCQkJCQkJ CSAgfCAoImF0dHJpYnV0ZSIgIjo6IikNCgkJCQkJCQkJCSAgfCAoInNlbGYiICI6OiIpDQoJCQkJ CQkJCQkgIHwgKCJkZXNjZW5kYW50LW9yLXNlbGYiICI6OiIpDQoJCQkJCQkJCQkgIHwgKCJuYW1l c3BhY2UiICI6OiIpDQpbMTddCVJvb3RlZEZ1bmN0aW9uTmFtZQkJIDo6PSAgKCdRe2h0dHA6Ly93 d3cudzMub3JnLzIwMDUveHBhdGgtZnVuY3Rpb25zfScgfCBQcmVmaXhQICc6JykgRnVuY3Rpb25M b2NhbE5hbWUNClsxOF0JUm9vdGVkRnVuY3Rpb25Mb2NhbE5hbWUJIDo6PSAgJ2RvYycgDQoJCQkJ CQkJCSAgICAgIHwgJ2lkJw0KCQkJCQkJCQkJICB8ICdlbGVtZW50LXdpdGgtaWQnDQoJCQkJCQkJ CQkgIHwgJ2tleScNClsxOV0JUHJlZml4UAkJCQkJIDo6PSAgUHJlZml4WE1MTlM=