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 non-normative Appendix J.1.3 states: If backwards compatible behavior is enabled for an xsl:apply-templates or xsl:apply-imports instruction, and the instruction causes a built-in template rule to be invoked, then the built-in template rule ignores any parameters that are passed: it does not pass them on to any further template rules. There is no normative statement to back this up. It appears to contradict the normative statement in 6.6: If the built-in rule was invoked with parameters, those parameters are passed on in the implicit xsl:apply-templates instruction. I don't recall the history of this one off-hand: I know it was discussed at some length.
Some further input on this: see http://www.w3.org/TR/2005/WD-xslt20-20050211/#changes-2005-02 "Changes in the February 2005 draft" including the following: The behavior of certain constructs in backwards-compatible mode has changed to more closely reflect the XSLT 1.0 behavior. Specifically: ... In backwards compatible mode, parameters passed to a built-in template rule are not passed on. It looks as if we made a decision to make this change, added it to the change log and to the non-normative "backwards compatibility" appendix, but failed to make any change to the normative section (6.6 Built-In Template Rules) where it belongs.
In discussion, the working group decided that parameters should be passed through the built-in templates even in backwards-compatibility mode. The relevant entry has therefore been removed from J.1.3, and a new entry describing the incompatibility has been added to J.1.4.