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 23329 - [xslt3.0] xsl:next-match and templates using union patterns
Summary: [xslt3.0] xsl:next-match and templates using union patterns
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Working 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: 2013-09-23 13:40 UTC by Michael Kay
Modified: 2014-05-15 14:00 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2013-09-23 13:40:53 UTC
Consider <xsl:template match="a[xx] | a[yy]">

For xsl:next-match we have a Note that says:

As explained in 6.4 Conflict Resolution for Template Rules, a template rule whose match pattern contains multiple alternatives separated by | is treated equivalently to a set of template rules, one for each alternative. This means that where the same item matches more than one alternative, and the alternatives have different priority, it is possible for an xsl:next-match instruction to cause the current template rule to be invoked recursively. This situation does not occur when the alternatives have the same priority.

(1) the reference to 6.4 is incorrect, it should be to 6.5.

(2) In the relevant rule in 6.5 it says "However, it is not an error if an item matches more than one of the alternatives.". In 3.0 this would not be an error anyway, so the sentence is obsolete.

(3) The sentence "This situation does not occur when the alternatives have the same priority." appears unfounded. In the above example, the alternatives have the same priority, and there doesn't seem to be any normative statement about what xsl:next-match does in this case. I think we should say that the rule "the template rule is treated equivalently to a set of template rules, one for each alternative" applies only if there is no explicit priority and the alternatives have different default priority. If they have the same (explicit or implicit) priority, then we should behave as if there is only one template rule, which means that next-match will not select the rule more than once.
Comment 1 Michael Kay 2013-09-25 16:14:50 UTC
In looking at this none of us were enamoured of the 2.0 specification, but decided that the simplest extension of compatible behaviour was to say that we always treat a union pattern as defining multiple template rules, and we treat the "declaration order" of these rules (which affects their ranking during conflict resolution and next-match) as being the order of branches of the union.

We should note also that this splitting applies ONLY if there is no explicit priority attribute.
Comment 2 Michael Kay 2013-09-26 07:29:09 UTC
These changes have been applied.