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 "XSL Transformations (XSLT) Version 3.0" working draft specification of 10 July 2012 defines EBNF for patterns, which allows parenthesized patterns. At the same time in section 6.5 doesn't have special rule for parenthesized expression, the only: 11. In all other cases, the priority is +0.5. Therefore, if I use pattern "/", then it's default priority calculated as "-0.5". But if to write match="(/)" - the priority will be "+0.5". It confuses me, because I thought that "/" and "(/)" could be used as equivalent expressions. Similar misunderstanding could be when I use union in parenthesized expression, for example: patterns "a | b" vs "(a | b)": The first pattern is an equivalent to two separate template rules: match="a" and match ="b". And each separate template rule has it's own default priority - "0". The second pattern we could not devide into two separate template rules, therefore the default priority is calculated to whole pattern and equals "+0.5". Thank you, Vitaliy
Your understanding of the current specification is correct. Basing the default priority on the syntactic form of the pattern has always had the potential to create anomalies, for example many people are caught out that match="//a" has a different priority to match="a". We have to find a compromise between keeping the rules simple and easy to explain, and giving intuitive results for people who do not know the rules. It would certainly be possible to have a rule that redundant outer parentheses are stripped before applying the other rules.
(In reply to comment #1) > Your understanding of the current specification is correct. > > Basing the default priority on the syntactic form of the pattern has always > had the potential to create anomalies, for example many people are caught > out that match="//a" has a different priority to match="a". We have to find > a compromise between keeping the rules simple and easy to explain, and > giving intuitive results for people who do not know the rules. > > It would certainly be possible to have a rule that redundant outer > parentheses are stripped before applying the other rules. Thank you, for response. Yes, probably a good solution just to remove unnecessary parentheses before default priority calculation. Could be the pattern EBNF be simplified as following: Pattern30 ::= ParenthesizedPattern | Pattern Pattern ::= PatternTerm ( ('|' | 'union') PatternTerm )* ParenthesizedPattern ::= '(' Pattern ')' QualifiedPattern ::= ParenthesizedPattern PredicateList Thank you, Vitaliy
In the current internal WD, the following Note was added: "The rules are based on the raw syntax of the pattern as written. So, for example, enclosing a pattern in parentheses changes its priority; and the rule that a template rule with match="a|b" is treated as two separate template rules does not apply if the pattern is written as match="(a|b)"." I'm not sure whether the editor's intention was to expand on this or change it in a later draft. This fixes the problem spec-wise, but I believe we can do better. It benefits both users and implementations if they are allowed to remove the redundant parenthesis, if and only if they encompass the whole expression. Otherwise, we cannot rewrite (a | b) as a | b, which I think is odd and counter-intuitive, and removes the ability to expand that expression as multiple matching templates match="a" and match="b".
The paragraph was added as clarification of the existing rules, because when a reader of the spec says confusion and misunderstanding are possible then it's best to assume that they are right. It doesn't prejudge whether we might be able to change/improve the rules.
The WG resolved to add the following rule as the first rule in 6.5, which has the effect that redundant outer parentheses do not affect the semantics: <p>If the top-level pattern is a ParenthesizedExprP then the outer parentheses are effectively stripped; these rules are applied recursively to the UnionExprP contained in the ParenthesizedExprP.</p>