This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There's an inconsistency in the rules for forwards-compatibility mode (section 3.9). It says: <quote> Within a section of a stylesheet where forwards-compatible behavior is enabled, errors that would normally be static errors are treated instead as dynamic errors. This means that no error is signaled unless the construct containing the error is actually evaluated. This includes, but is not limited to, the following situations: </quote> and then, inter alia: <quote> if an element has an optional attribute with a value that XSLT 2.0 does not allow the attribute to have, then the attribute must be ignored. </quote> The first statement would suggest that if the instruction <xsl:copy copy-namespaces="not-on-your-nelly"/> is actually executed, it should be treated as a dynamic error. The second statement suggests that this instruction should be evaluated as if it were <xsl:copy/>. (This was the XSLT 1.0 rule, and I believe is the correct one.)
Agreed we need to fix this, editor will email the revised text to the WG before applying it.
Some further observations: I've been running my 2.0 tests through my 1.0 processor to see what happens. One observation is that <xsl:value-of> with no select attribute fails. There's nothing in the 1.0 rules for forwards compatibility that says a 1.0 processor should anticipate that an attribute that's mandatory in 1.0 might become optional in 2.0. Logically one should add the rule that in forwards compatible mode, the absence of a mandatory attribute is an error only if the instruction is actually evaluated. Another observation: I found myself wanting to mark a stylesheet as being suitable for use only with XSLT 2.0, so that a 1.0 processor would reject it. The most effective way of doing this, perversely, is to specify version="1.0", so that a 1.0 processor will report any 2.0 constructs as errors, while a 2.0 processor runs the stylesheet happily. It's not easy to see a way around this. One way might be to allow the syntax version="2.0 only" (or version="2.0 and above") which a 1.0 processor will reject as an invalid version attribute. In the 2.0 appendix on backwards compatibility, we fail to mention that a stylesheet that uses XSLT 2.0 constructs and specifies version="2.0" may produce different results when run on a 1.0 processor (in FC mode)and when run on a 2.0 processor. Some cases where this happens include: (a) <xsl:attribute name="x" select="12"/> A 2.0 processor outputs a="12", a 1.0 processor in fcm outputs a="". (b) <xsl:character-map> A 1.0 processor in fcm ignores this element (c) <xsl:apply-templates mode="#current"/> A 1.0 processor in fcm ignores the mode attribute Michael Kay
Following discussion, the working group decided that the new use-when attribute meets many of the requirements that originally relied on forwards compatibility mode, and that it was therefore possible to reduce the differences that apply in this mode. In particular, the existing design causes static errors to be demoted to dynamic errors so that version-specific code can be made conditional using xsl:choose; this is no longer necessary given that we now have a compile-time conditional. The forwards compatibility section is therefore rewritten as follows: <p>The intent of forwards-compatible behavior is to make it possible to write a stylesheet that takes advantage of features introduced in some version of XSLT subsequent to XSLT 2.0, while retaining the ability to execute the stylesheet with an XSLT 2.0 processor using appropriate fallback behavior.</p> <p>It is always possible to write conditional code to run under different XSLT versions by using the <code>use-when</code> feature described in [XXX]. The rules for forwards-compatible behavior supplement this mechanism in two ways:</p> <ulist> <li><p>certain constructs in the stylesheet that mean nothing to an XSLT 2.0 processor are ignored, rather than being treated as errors</p></li> <li><p>explicit fallback behavior can be defined for instructions defined in a future XSLT release, using the <elcode>xsl:fallback</elcode> instruction.</p></li> </ulist> <p>The detailed rules follow.</p> <p><termdef id="dt-forwards-compatible-behavior" term="forwards-compatible behavior">An element enables <term>forwards-compatible behavior</term> for itself, its attributes, its descendants and their attributes if it has an <code>[xsl:]version</code> attribute (see <specref ref="standard-attributes"/>) whose value is greater than <code>2.0</code>.</termdef></p> <p>An element that has an <code>[xsl:]version</code> attribute whose value is less than or equal to <code>2.0</code> disables forwards-compatible behavior for itself, its attributes, its descendants and their attributes. The compatibility behavior established by an element overrides any compatibility behavior established by an ancestor element.</p> <p>These rules do not apply to the <code>version</code> attribute of the <elcode>xsl:output</elcode> element, which has an entirely different purpose: it is used to define the version of the output method to be used for serialization.</p> <p>Within a section of a <termref def="dt-stylesheet">stylesheet</termref> where forwards-compatible behavior is enabled:</p> <ulist> <item> <p>if an element in the XSLT namespace appears as a child of the <elcode>xsl:stylesheet</elcode> element, and XSLT 2.0 does not allow such elements to occur as children of the <elcode>xsl:stylesheet</elcode> element, then the element and its content <rfc2119>must</rfc2119> be ignored.</p> </item> <item> <p>if an element has an attribute that XSLT 2.0 does not allow the element to have, then the attribute <rfc2119>must</rfc2119> be ignored.</p> <p>if an element in the XSLT namespace appears as part of a <termref def="dt-sequence-constructor">sequence constructor</termref>, and XSLT 2.0 does not allow such elements to appear as part of a sequence constructor, then:</p> <olist><li><p>If the element has one or more <elcode>xsl:fallback</elcode> children, then no error is reported either statically or dynamically, and the result of evaluating the instruction is the concatenation of the sequences formed by evaluating the sequence constructors within its <elcode>xsl:fallback</elcode> children, in document order. Siblings of the <elcode>xsl:fallback</elcode> elements are ignored, even if they are valid XSLT 2.0 instructions.</p></li> <li><p>If the element has no <elcode>xsl:fallback</elcode> children, then a static error is reported in the same way as if forwards-compatible behavior were not enabled.</p></li> </olist> </item> </ulist> Since the bug was raised internally within the WG, it will now be closed. Michael Kay for the XSL WG
Some further changes have been made to implement the decision recorded for this bug. Errors XTSE0330 and XTDE0331 described special handling of the errors that arise when an XPath expression calls an unknown function: this now follows the standard XPath rules, so the special errors are not needed.