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 table in section "5.4.4 Additional Dynamic Context Components used by XSLT" specifies that the current template rule (CTR) is cleared by xsl:for- each-group, xsl:matching-substring, xsl:non-matching-substring. It implies that the CTR is NOT cleared when an XSLT processor executes xsl:fallback children of xsl:analyze-string, however CTR is always cleared within xsl:fallback children of xsl:for-each-group. Moreover, the previous row of the table specifies that the focus is set by xsl:analyze-string - i.e. not only within its xsl:matching-substring and xsl:non-matching-substring children, but also within its xsl:fallback children. Though it may concern only XSLT 2.0 processors working in backwards-compatible mode, or early XSLT processors that do not implement XSLT 2.0 in full, it makes sense to be consistent in both cases. The proposal is to specify that CTR is cleared by (and the focus is set by) "successful" execution of xsl:for-each-group, xsl:analyze-string, when no fallbacks performed. If you decide this clarification is not worth it, we at least should be consistent in putting (xsl:analyze-string) OR (xsl:matching-substring, xsl:non- matching-substring) in the first two rows of the table.
An XSLT 2.0 processor never executes the xsl:fallback child of an xsl:analyze-string or xsl:for-each-group instruction (even in backwards compatibility mode), so the 2.0 spec doesn't need to say what should happen if it does. It's up to the 1.0 spec to define what an XSLT 1.0 processor does. I agree that editorially, it might be clearer to remove xsl:matching-substring and xsl:non-matching-substring from the second row of the table, and put xsl:analyze-string there instead. But there's no substantive difference. Michael Kay (personal response)
The XSL Working Group agreed that it was unnecessary to describe the action of an xsl:fallback child of xsl:for-each-group or xsl:analyze-string, since such an xsl:fallback instruction is ignored by an XSLT 2.0 processor. The WG also accepted the change proposed in the second paragraph of my provisional response. I am marking this as fixed; if there are any problems with this resolution, please re-open the bug. Michael Kay XSLT 2.0 editor