[Bug 3162] New discretionary choice in xsl:number?

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3162


mike@saxonica.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor




------- Comment #1 from mike@saxonica.com  2006-04-28 09:13 -------
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.

Received on Friday, 28 April 2006 09:13:33 UTC