This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Appendix J.1.3, item 8, states: If the expression in the value attribute of xsl:number returns an empty sequence or a sequence including non-numeric values, an XSLT 2.0 processor may signal a recoverable error; but with backwards compatibility enabled, it outputs NaN. Yet chapter 12 does not mention any recoverable error. Should this appendix say "MUST signal a non-recoverable error"?
You are right, this non-normative paragraph reflects an older version of the specification. The error conditions have become non-recoverable. In fact, the "empty sequence" case is not an error under 2.0, and the "sequence including non-numeric values" is a non-recoverable error. As this is non-normative text whose only purpose is to summarise what is already stated in the normative part of the specification, I propose to treat it as editorial. I have accordingly merged this list item into list item 3, which now reads: <item><p>If the expression in the <code>value</code> attribute of the <elcode>xsl:number</elcode> instruction returns a sequence of more than one item, then under XSLT 2.0 all items in the sequence will be output, as defined by the <code>format</code> attribute, but under XSLT 1.0, all items after the first will be discarded. If the sequence is empty, then under XSLT 2.0 nothing will be output (other than a prefix and suffix if requested), but under XSLT 1.0, the output is "NaN". If the first item in the sequence cannot be converted to a number, then XSLT 2.0 signals a non-recoverable error, while XSLT 1.0 outputs "NaN".</p></item> I have made the above change to the text, but will leave the bug open so it can be reviewed by the WG. There's another possible incompatibility in this area which we don't mention: in XSLT 2.0 it's an error to specify <xsl:number value="-1"/>, whereas XSLT 1.0 doesn't say what happens in this case (all it says is that it can't happen, which isn't true). I think this stone is best left unturned.
The WG reviewed this response and agreed with it.