format-number underspecified (Was: XSLT 1.1 comments f

| is probably Uche; > is Steve Muench:\

| format-number() is another case in point of this. It  causes *real* pain
| when an implementor has to find away to implement such an
| awkward mechanism when his language has perfectly useful, and far more
| mature, numerical formatting constructs. I bet you implemented
| format-number() in OracleXSL in ten minutes. It has taken the 4XSLT
| implementors a dreadful amount of work.

>Oracle has both Java and C implementations. I did not hear the developers
>of our C implementation complaining about format-number(). They just
>implemented the behavior as noted in the spec.

What spec is that, Steve? I have not seen a spec that is complete enough
to cover all the details. I consider it a big conformance issue. Here
are my prior comments within the Xalan community:
1. The XSLT spec doesn't say that format-number() MUST behave
   exactly like the Java DecimalFormat class for output.
2. Xalan-C++ ... doesn't have the luxury
   of handing the arguments to a JRE and hoping for the best.
3. Even the Java spec for DecimalFormat does not fully define the behavior
   at the necessary level of detail. Among the unaddressed issues:
   A. Whether setting the zero-digit is supposed to reset the whole 0-9
range.
[E.R. Harold later found a place where it does in the 1.3 spec, but XSLT
defines
 behavior per the JDK 1.1 spec.]
   B. Placement of % and ? at the right end.
   C. Effects of multiple % and/or ?.
   D. Whether the negative-number sub-pattern resets all characteristics.
   E. Effects of multiple pattern-separators.

In particular (3D) above has been noted as a problem by Ken Holman
that is affecting the content of his XSLT training material.
.................David Marston


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list