RE: XSLT 1.1 draft: no enhancement of format-number

By a cursory examination, there appears to be no difference between JDK 1.2's DecimalFormat and JDK 1.3's (of course, they have scientific notation and currency support that JDK 1.1's doesn't).
Whether you reference JDK 1.2 or JDK 1.3 is not significant to me.

Though just augmenting format-number with the capabilities added in JDK 1.2 by itself would add some value (as suggested in previous emails in this thread), effective use (without resorting to
scripting) requires a more capable mechanism than XPath's number() function to convert strings to IEEE doubles.

My suggestion would be to add a parse-number() function to XSLT 1.1 that parallels the DecimalFormat.parse() method in the JDK.  There would be some functional overlap between number() in XPath and
parse-number in XSLT, however I think it is cleaner to keep them separate.

The form of the function would be: 

parse-number(string,format) ==> number
parse-number(string,format,qname of xsl:decimal-format) ==> number 

Without this, you could resort to script to convert the source strings into numbers, however, this method provides precise symmetry with format-number() that might be difficult to mimic in script.

I don't think that the value of this function would be eliminated (but may be possibly reduced) by future support for schema datatypes in later versions of XSLT as deployed data may not fit the strict
lexical constraints of the schema datatypes (for example, Arabic or Indic digits for instances) and would be typed as strings with pattern constraints.

Support for this in Java-based XSLT processors should be trivial since it leverages the DecimalFormat infrastructure already used for format-number(). For non-Java processors, some code would need to
be written to coerce the strings down to the forms accepted by the platform's string to double conversion facilities, but that code shouldn't be rocket science.

Though the whole issue could be deferred by just doing everything in script, I believe that string to numeric coersion is central enough to XSLT to warrent explicit constructs to support it and that
XSLT 1.1 provides a good opportunity to fix this.

p.s. Coverage of format-number in Michael Kay's XSLT Programmer's Reference seems to imply that scientific notation is already supported in XSLT 1.0 (pg 82 first pp, pg 458 second pp), however
scientific notation is not mentioned in the JDK 1.1 DecimalFormat (http://java.sun.com/products/jdk/1.1/docs/api/java.text.DecimalFormat.html#_top_) but receives a substantial converage in JDK 1.2's
http://java.sun.com/products/jdk/1.2/docs/api/java/text/DecimalFormat.html  It may be a defacto capability of Java based XSLT processors running on JDK 1.2 or later systems (or perhaps exploits an
undocumented feature on JDK 1.1), however I don't think it is part of the standard.

Received on Friday, 5 January 2001 13:07:09 UTC