[Bug 5849] [XSLT 2.0] xsl:number problem

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





--- Comment #2 from Michael Kay <mike@saxonica.com>  2008-07-10 22:26:00 ---
I agree entirely with the analysis of the XSLT 1.0 spec in comment #1. Indeed,
the results match what Saxon 6.5.5 outputs, with one exception: Saxon numbers
a[1] as nr="1". The spec doesn't say what happens if there is no node that
matches the "from" pattern; Henry decided to discard all the nodes, whereas in
Saxon I guess I decided to retain them all.

According to various contributors to the xsl-list, here's a survey of what
various products do with this stylesheet. The eight columns are the values of
the nr attribute on the 8 <a/> elements, with "-" indicating that the attribute
is empty.

Saxon 6.5.5     1 1 2 3 4 1 2 3
Saxon 9.1.0.1   - 2 3 4 5 6 7 8
Saxon 9.1.0.2   - 2 3 4 5 2 3 4
Gestalt         - 2 3 4 5 6 7 8
Xalan 1.9       0 2 3 4 0 6 7 8
LibXSLT 1.1.22  1 2 3 4 1 2 3 4
Xalan-C 1.10    0 2 3 4 0 6 7 8
Xalan-J 2.7.1   0 2 3 4 0 6 7 8
Intel           1 2 3 4 5 6 7 8
MSXML3          0 1 2 3 0 1 2 3
.NET 1.0        - 1 2 3 - 1 2 3
.NET 2.0        - 1 2 3 4 1 2 3

As far as I can see the only two results that are defensible are

        (a)     - 1 2 3 4 1 2 3
        (b)     1 2 3 4 1 2 3 4

with the main argument in favour of (a) being backwards compatibility with the
1.0 spec, though since implementations are so inconsistent this cannot be a
very strong argument. The XSLT 2.0 spec, which produces

        (c)    - 2 3 4 5 2 3 4

does not seem defensible: if the "from" node is regarded as the last in the
previous run, then the first node after the "from" node should be numbered 1,
not 2.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 10 July 2008 22:26:48 UTC