Re: [xslt] format-number inconsistent with java results

[Bjorn Reese <breese mail1 stofanet dk>]

Ken Neighbors wrote:
> 
> I was trying to format a fractional number *without* a leading zero,
> but was unable to.  For example, format-number(0,'.0') returns "0.0"
> instead of ".0" as I would expect.

IMHO, relying on JDK 1.1 is the biggest mistake made in XSLT 1.0 because
of its vague descriptions. The three cases you mention here belong to this
category.

o Leading zeroes.

  I have not been able to find anything in JDK 1.1 or XSLT 1.0 which
  supports your assertion that numbers can be formatted as ".0". It
  actually appears as if you have specified an illegal format. According
  to JDK 1.1 the format can be

    pattern    := subpattern{;subpattern}
    subpattern := {prefix}integer{.fraction}{suffix}
    prefix     := '\\u0000'..'\\uFFFD' - specialCharacters
    suffix     := '\\u0000'..'\\uFFFD' - specialCharacters
    integer    := '#'* '0'* '0'
    fraction   := '0'* '#'*

  From the subpattern rule we can see that the integer part must always
  be present, and that there must always be at least one '0' in the
  integer part.

  From a standards point of view, what you are trying to achieve is not
  possible.

o Trailing decimal points.

  Neither JDK 1.1 nor XSLT 1.0 is explicit about this. JDK has a method
  called setDecimalSeparatorAlwaysShown(), and it appears that the Zvon
  results have been produced with this. However, JDK does not list the
  default value of this behaviour, nor does XSLT indicate whether or not
  this behaviour must be used.

  The only clue that can be extracted from JDK 1.1 is the above subpattern
  line. As the decimal point may or may not be present in the formatting
  line, I believe that it makes most sense only to output a trailing zero
  if the decimal point has been specified in the formatting string.

  This also means that libxml gets the following (and related) wrong

    format-number(-1.0,'0.' ) :      -1 : -1.

o Rounding.

  I agree that 0.5 must be rounded up (and -0.5 down). Java adheres to
  IEEE 754 round-to-nearest semantics (although it does not support other
  required IEEE 754 rounding modes), so Java should produce these results
  as well. I have no idea why the Zvon examples does otherwise.

I think that most of the above boils down to the question about whether
or not we want to deviate from (extend upon) the standards. We have done
so before.

So the question is, do we want to support

  1. Omission of the integer part in the formatting string (e.g. '.0')
  2. Omission of required zero in integer part (e.g. '#.0')

If we do, then I think Ken's patch solves the problem.

My position on this? I hate it when standards makes unnecessary restrictions,
so I say go.