xsl:number when no matching nodes

[Andy Fish]

In my XSLT stylesheet, if I call

<xsl:number level="any" count="sdfsjdfjsdfksndfn"/>

where there are no preceeding nodes called "sdfsjdfjsdfksndfn" I would
expect it to return 0. However, on the XSLT processor I'm using (.net
framework 1.1) it seems to return an empty string (or possibly an empty node
set)

I had a look here: http://www.w3.org/TR/xslt and I can't find any
specification of what should happen if xsl:number can't find any nodes to
number. Is it safe to rely on the "empty string" behaviour?

Andy

 

[Martin Honnen]

In my XSLT stylesheet, if I call

<xsl:number level="any" count="sdfsjdfjsdfksndfn"/>

where there are no preceeding nodes called "sdfsjdfjsdfksndfn" I would
expect it to return 0. However, on the XSLT processor I'm using (.net
framework 1.1) it seems to return an empty string (or possibly an empty node
set)

I had a look here: http://www.w3.org/TR/xslt and I can't find any
specification of what should happen if xsl:number can't find any nodes to
number. Is it safe to rely on the "empty string" behaviour?

I have tried with MSXML, with Saxon, and with Xalan, the latter produces
a 0, the other ones an empty string.
So that seems indeed to be an area where processor behaviour differs.

 

[Andy Fish]

I have tried with MSXML, with Saxon, and with Xalan, the latter produces a
0, the other ones an empty string.
So that seems indeed to be an area where processor behaviour differs.

Thanks Martin,

I would have thought 0 is more logical. Still, putting a test for '' and
turning it into a 0 is compatible with them all so it's no big deal.

 

[David Carlisle]

So that seems indeed to be an area where processor behaviour differs.

Note that there are some clarifications/errata in the area of xsl:number
on no matching nodes

http://www.w3.org/1999/11/REC-xslt-19991116-errata/#E23

so some processors may have been fixed before this clarification was
made...

David