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 way I understood pattern expressions is that there are predicate patterns, rooted patterns and path patterns. * Predicate patterns start with "." * Rooted patterns start with a variable like $x, or a function like doc() or id() * Path patterns start with "/", "//" , or a nodetest (nametest or kindtest) The relevant part for this discussion is: RelativePathExprP ::= StepExprP (("/" | "//") StepExprP)* StepExprP ::= PostfixExprP | AxisStepP PostfixExprP ::= ParenthesizedExprP PredicateListXP30 ParenthesizedExprP ::= "(" UnionExprP ")" This means that a RelativePathExprP can also be: RelativePathExprP ::= ParenthesizedExprP (("/" | "//") ParenthesizedExprP)* Since ParenthesizedExprP is defined as UnionExprP, it can be any pattern, except for a predicate pattern. That is, it can also be a rooted pattern. That means (if I understand the grammar correctly) that the following are legal patterns: * a/(id('test')) * b/(c | d)/(e | f) * c/((root() | id('test')) * id('test')/(root() | d/e) * e/($foo | $bar) I am not sure this is intentional and I am not sure what the result of such expressions should be. I looked through the tests but think we do not have tests with these patterns. It probably doesn't make much sense using those expressions, but there must have been a reason that previously functions were not allowed to be used anywhere else than at the root of the pattern (XSLT 2.0). This begs the question, how should these be treated? My gut tells me that, assuming this was intentional, that those expressions should work like in XPath, that is, the context for these functions is the context they would have in XPath. I can't think of anything logical for an expression like e/($foo) though. If this was not intentional, we should fix it, if it is intentional, we should create some tests, but perhaps also clarify this in an erratum entry.
It's certainly rather strange that the grammar allows doc('a.xml')/(id('a123')) but not doc('a.xml')/id('a123') But although it's strange, I think the semantics are well defined.
A draft erratum E18 was published on 13 Feb 2019, HTML version: https://htmlpreview.github.io/?https://github.com/w3c/qtspecs/blob/master/errata/xslt-30/html/xslt-30-errata.html#E18 I think the proposed text (a Note) covers this case perfectly.