Really, when you get results that are as obviously broken as this, you
should tell us which XSLT processor you are using.
(But before you do that it's always worth checking to see that another
processor gives the answer you expected. However sure you are that your
own code is correct, you can be wrong.)
Incidentally, XSLT 1.0 isnt' very specific about exactly how rounding
should be done in format-number(). It refers to the JDK 1.1 spec, which
doesn't say. Later versions of the JDK are much more specific, however.
Later versions of the spec also document some bugs which XSLT
implementations may or may not reproduce, for example the fact that most
of the negative sub-picture gets ignored.
Michael Kay
We've encountered a problem with format-number where-by the
value part actually changes according to the precision.
XML:
<?xml version="1.0" encoding="UTF-8"?>
<AR_ITEMS elem="4">
<EVENTS elem="1">
<TOTAL elem="826">
<AMOUNT>0.00000073173</AMOUNT>
</TOTAL>
</EVENTS>
<EVENTS elem="2">
<TOTAL elem="826">
<AMOUNT>0.0000073173</AMOUNT>
</TOTAL>
</EVENTS>
<EVENTS elem="3">
<TOTAL elem="826">
<AMOUNT>0.000073173</AMOUNT>
</TOTAL>
</EVENTS>
<EVENTS elem="4">
<TOTAL elem="826">
<AMOUNT>0.73173</AMOUNT>
</TOTAL>
</EVENTS>
<EVENTS elem="5">
<TOTAL elem="826">
<AMOUNT>0.073173</AMOUNT>
</TOTAL>
</EVENTS>
<EVENTS elem="6">
<TOTAL elem="826">
<AMOUNT>0.00073173</AMOUNT>
</TOTAL>
</EVENTS>
</AR_ITEMS>
0.0000
0.0000
0.1000
0.7317
0.7320
0.7000
....we never fixed this so we though that we'd correct the
rounding in the source program. This worked OK, as long as we
had a full complement of digits after the decimal point. When
we have a number with less, say 0.7320, it is being displayed at 0.732
Anybody ever comes across either of these problems and
resolved them or found them to be persistent bugs?
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list