This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider this example if the input is <doc><x/></doc>: <xsl:template match="doc"> <out> <xsl:apply-templates select="x"/> </out> </xsl:template> <xsl:template match="*:x|element(x)"> <foo/> <xsl:next-match /> </xsl:template> <xsl:template match="node()"> <bar/> </xsl:template> Is the output: <out><foo/><bar/></out> or <out><foo/><foo/><bar/></out> note that the priority for element(x) is 0 *:NCNAME is -.25 node() is -.5 It seems odd to me that xsl:next-match can match the template that it's declared in. Is this the intention of the working group? In section 6.4 Conflict Resolution for Template Rules: "If the pattern contains multiple alternatives separated by | , then the template rule is treated equivalently to a set of template rules, one for each alternative. However, it is not an error if a node matches more than one of the alternatives." In section 6.7 Overriding Template Rules: "the xsl:next-match instruction considers all other template rules of lower import precedence and/or priority."
Good point. I think the output has to be <out><foo/><foo/><bar/></out>: that is, we really do treat it as if the union template rule was "rolled out" into two separate rules, one for each branch of the union. The results might be odd, but anything else is likely to be odder. For example consider a case where the matching templates in order of decreasing priority are T1, T2, T1, T3: we have to say that if the first match is T1, then successive next-match calls will invoke T2, T1, and T3 in that order. Your case is the same but with T2 removed. I think this is currently well-specified even if the consequences might not have been predicted. Michael Kay
Thank-you for the clarification. I prefer the output to be <out><foo/><foo/><bar/></out>. I suggest adding a warning in section 6.7 that xsl:next-match can match a template that it's declared in. thanks, Joanne
The XSL WG considered this at the telcon this week and directed the editor to add a Note explaining the behavior. This note will be added after the bullet in 6.7 explaining the effect of xsl:next-match, and reads as follows: <note diff="add" at="ZA">As explained in <specref ref="conflict"/>, a template rule whose match pattern contains multiple alternatives separated by code>|</code> is treated equivalently to a set of template rules, one for each alternative. This means that where the same node matches more than one alternative, and the alternatives have different priority, it is possible for the <elcode>next-match</elcode> instruction to cause the current template rule to be invoked recursively. This situation does not occur when the alternatives have the same priority.</note>
The change has been applied to the document so the bug is now closed.