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.