Request for more clarity on decimal-format

Section 12.3 of the XSLT 1.0 Recommendation often refers to the Sun JDK 1.1
DecimalFormat class, though it seems to carefully *not* say that an XSLT
processor must produce the same output as this class. I'm finding it
difficult to ascertain what constitutes conformant behavior, since there
seem to be no published details on the JDK that can be treated as
normative.

Here are specific trouble spots:
[zero-digit-sets-others] The XSLT 1.0 Recommendation describes the
zero-digit character as "the character used as the digit zero" but says
nothing about digits 1-9 following in sequence. This could mislead the
reader into thinking that setting this character only changes zero. The JDK
actually sets the whole vector of 0-9 characters when the zero-digit is
set, and the XSLT processors I commonly use observe that precedent. I think
that XSLT should say that the whole 0-9 vector is altered, if indeed that
is the intended behavior. In the errata and newer specs I've seen, the
sentence about zero-digit is unchanged.

[format-pattern-character-precedence] By study of the JDK source or by
throwing enough decimal-format patterns at an XSLT processor, one can
discern that there is a sequence of operations in formatting. For example,
finding the decimal separator, if there is one, must precede finding the
grouping separator, which is only a formatting character when found to the
left of the decimal separator. Locating the decimal separator also affects
the interpretation of 0 vs. # characters. I would like the XSLT spec to
state some precedence rules and also define some errors in the pattern.
Ideally, this would take the form of a complete sequence of operations for
formatting, but any rules should be stated.

[per-mille-shift-places] A percent character at the end of the format
pattern string causes the number to be multiplied by 100, and a per-mille
character causes multiplication by 1000. Some JDKs, apparently including
Sun JDK 1.1, have a problem with recognition of significant figures.
Consider this stylesheet:
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    version="1.0">

<xsl:output method="xml" encoding="ISO-8859-1"/>

<xsl:template match="/">
 <out>
  <xsl:value-of select="format-number(0.4857,'###.###%')"/>
  <xsl:text>, </xsl:text>
  <xsl:value-of select="format-number(0.4857,'###.000%')"/>
  <xsl:text>&#10;</xsl:text>
  <xsl:value-of select="format-number(0.4857,'###.###&#8240;')"/>
  <xsl:text>, </xsl:text>
  <xsl:value-of select="format-number(0.4857,'###.000&#8240;')"/>
 </out>
</xsl:template>

</xsl:stylesheet>

In the ###.000 cases, the stylesheet writer explicitly requested zeroes on
the right, so all JDKs produce 48.570% and 485.700&#8240; as one would
expect. The ###.### is consistently correct for percent, generating 48.57%
and recognizing that there are only four significant figures. However, JDKs
vary on the per-mille equivalent, some generating the objectively correct
485.7&#8240; (no extra zeroes), and some generating 485.700&#8240; which
isn't parallel to their % behavior. I think this is a JDK bug, which
unfortunately seems to occur with Sun JDK 1.1. Can the XSLT specs distance
themselves from this and other JDK bugs? From a conformance testing
perspective, the ideal is for the XSLT spec to state exactly what output
occurs for any characters in the pattern. Second best is for the spec to
cite, as normative, a freely-available document issued by a standards body.
.................David Marston

Received on Tuesday, 2 January 2001 15:42:06 UTC