RE: [xsl] formatting numbers

["Michael Kay" <mhk@xxxxxxxxx>]

> Thanks a lot for your help, David and Mike, it works perfect!
> 
> One more little question... What could be the issues if I 
> didn't use the
> translate option but only the decimal-format and format-number?
> 

You might wish that you hadn't asked this little question.

The XSLT 1.0 specification at http://www.w3.org/TR/xslt#format-number
states:

"The format pattern string is in the syntax specified by the JDK 1.1
DecimalFormat class."

The word "DecimalFormat" is a hyperlink to a URL on the Java site that no
longer exists; Appendix A of the specification contains no normative
reference to any Java specifications.

There is another sentence: "The format pattern must not contain the currency
sign (#x00A4); support for this feature was added after the initial release
of JDK 1.1. "

However, there is no definitive statement as to which precise version of the
JDK 1.1 specification is referenced. The Documentation archive at
http://java.sun.com/products/archive/index.html gives you a choice of eight
or nine sub-versions. If we take the version at

http://java.sun.com/products/archive/jdk/1.1/index.html

it actually says it's version 1.1.8. There is no date, so it's not possible
to tell whether this is the version that was current at the time XSLT 1.0
was published. Fortunately it's only 3.5Mb - the JDK was smaller in those
days. Most of the files are dated 5/4/99 (that's 5th April for those of you
who write the date the wrong way round).

In this version of java.lang.DecimalFormat, it says that the apostrophe is
"used to quote special characters in a prefix or suffix."

The question is now: what happens if the grouping separator is set to be an
apostrophe? XSLT defines this by reference to the Java DecimalFormatSymbols
class. And here the trail stops cold: the Java spec simply doesn't say
whether this is allowed or not, or what the effect is.

The JDK 1.4.2 specification for DecimalFormat is vastly improved (for
example, it now defines the rounding algorithm used!), but it still offers
no clear answer to this question.

XSLT 1.0 processors written in Java are very likely to use the Java
DecimalFormat class in their underlying implementation. This means that they
will often behave the way the current JDK behaves, which is not necessarily
the JDK 1.1 behaviour as required by the XSLT spec. This is technically
non-conformant. There are also things that the JDK implementation does that
no-one could reasonably guess from the 1.1 specification (i.e., bugs) and
one could reasonably argue that such behaviours too are non-conformances
with XSLT 1.0. This explains why the behavior of Saxon 6.5.3 varies
depending on which Java VM you are using.

XSLT 1.0 processors written in other languages will emulate the Java
DecimalFormat behaviour as best they can, which is not easy, given that it
is so poorly specified, especially in the JDK 1.1 documentation. 

XSLT 2.0 no longer refers to the JDK specification, it defines
format-number() from first principles. It has dropped the special meaning
attached to an apostrophe in the format picture, so this particular problem
no longer arises.

Michael Kay