30402 2019-02-27 11:56:47 +0000 [XSLT30] Incorrect cross-reference for xsl:next-match 2019-02-28 15:29:10 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Recommendation PC All NEW P2 normal --- 1 mike mike abel.online public-qt-comments oldest_to_newest 129575 0 mike 2019-02-27 11:56:47 +0000 In § section 6.8 there is a Note starting "As explained in 6.4 Conflict Resolution for Template Rules, ...". The cross reference is incorrect. The rule it is referring to is in clause 2 of §6.5, Default Priority for Template Rules. 129576 1 mike 2019-02-27 12:26:36 +0000 Moreover, and perhaps more seriously, the relevant text in XSLT 2.0 said: 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. The last sentence has disappeared from the XSLT 3.0 specification. This would appear to mean that if you write <xsl:template match="p[@class='heading'] | p[@style='bold']"> and xsl:mode specifies on-multiple-match="fail", then you will get an error if any p element matches both branches of the union. This seems unfortunate. 129577 2 mike 2019-02-27 15:49:16 +0000 In §6.4 rule 3(a). after If the mode M has an xsl:mode declaration, and the attribute value on-multiple-match="fail" is specified in the mode declaration, a dynamic error is signaled. The error is treated as occurring in the xsl:apply-templates instruction, and can be recovered by wrapping that instruction in an xsl:try instruction. I propose adding: "However, no error is signaled if the matching template rules all form part of a set of template rules generated from a single xsl:template declaration whose match pattern is a union pattern (as described in §6.5 rule 2)" 129582 3 abel.online 2019-02-28 15:06:28 +0000 I agree to your suggestion in comment#2. Or as an alternative, we can remove the rule that a union pattern with '|' needs to be split into multiple template rules. I don't think the syntax is ambiguous if we remove that rule, and in fact, it should only be an implementation detail. 129583 4 mike 2019-02-28 15:08:38 +0000 Removing the rule gives a backwards compatibility problem because match="doc | node()" is supposed to behave like two rules with different priorities. It was probably a bad idea, but I think we're stuck with it. 129584 5 abel.online 2019-02-28 15:13:14 +0000 Looks like my alternative proposal would change current behavior after all, so that's a no-go. In fact, we have a specific Note on xsl:next-match saying: > a template rule with no priority attribute, 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, 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 template rule has an explicit priority. This implies that union'ed template rules with different default priority would be called again when xsl:next-match is invoked. I never realized this behavior was even possible, I wonder if we have a test covering this specifically. 129585 6 abel.online 2019-02-28 15:13:52 +0000 (In reply to Michael Kay from comment #4) > Removing the rule gives a backwards compatibility problem because match="doc > | node()" is supposed to behave like two rules with different priorities. > > It was probably a bad idea, but I think we're stuck with it. You came to the same conclusion at the same time ;) 129586 7 mike 2019-02-28 15:29:10 +0000 Yes, there are next-match tests for this (that's what got me here, they weren't working in one particular Saxon configuration).