W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2001

Re: XSLT 1.1 draft: no enhancement of format-number?

From: Curt Arnold <Curt.Arnold@hyprotech.com>
Date: Sun, 7 Jan 2001 02:17:11 -0600
Message-ID: <008501c07882$3d6fe9c0$f00ba8c0@houston.rr.com>
To: "James Clark" <jjc@jclark.com>
Cc: <xsl-editors@w3.org>
The XSLT requirements doc says that "The primary goal of the XSLT 1.1
specification is to improve stylesheet portability" which though enhancement
of the format-number() does not explicitly appear in the requirement doc, it
does improve the portability of stylesheets.

Based on a little informal testing, XT 199991105, SAXON 5.5.1 and Xerces
1.2.2 all support exponential notation in format-number() when running on
JDK 1.3 (I assume that would also under JDK 1.2) as a defacto extension of
XSLT 1.0.  The same stylesheet will produce different results or exceptions
when running under the same processors under JDK 1.1.  MSXML 3.0 does not
support exponential notation (but also does not support legal prefix or
suffix strings)

number() accepts exponential notation in defiance of the XPath spec (which
states it should return NaN) in MSXML3, Xalan, SAXON and XP (in both JDK 1.1
and JDK 1.3).

Exploiting these defacto extensions to the XSLT standard is an attractive
nuisance.  If you need exponetial notation, you can have it but at the cost
of having transforms that may not be portable.

As I mentioned in the previous message, these defacto extensions are
prevalent enough that Michael Kay's book documents the format-number
"extension" as if it is part of the standard.

Adapting format-number so that it references JDK 1.2 or JDK 1.3, adding
parse-number and adding tests in the conformance suites that number("1E15")
returns NaN would allow portable transforms dealing with numerics.
Otherwise, the most attractive solution is to write transforms that exploit
these known defacto extensions.

--  test.xml ---

 <test val="0"/>
 <test val="10000000"/>
 <test val="3.1415926"/>
 <test val="1E15"/>

--- test.xsl  ----

<xsl:stylesheet version="1.0"
<xsl:template match="/">

<xsl:template match="tests">

<xsl:template match="test">
 <result val="{@val}" formatted="{format-number(@val,'0.000000E00')}"/>



Running this transform on Java-platform processors on JDK 1.3, formatted the
results in exponential notation.  On JDK 1.1, the illegal format resulted in
exceptions.  Running Instant SAXON or XT.EXE resulted in a non-exponential
formatting with a 'E' appended (due to the dependance on the Microsoft Java
VM).  MSXML raised an exception.

Using "0.00000E" as the format resulted in exceptions on JDK 1.3 (where it
is an illegal pattern) and formatted the number in a non-exponential format
with an E appended on JDK 1.1 and with the Microsoft VM.  MSXML raised an
exception with the message that only 0, #, ., and commas were legal in the
format expression.  That isn't quite true since JDK 1.1 allowed an optional
prefix or suffix that did not contain special characters and 'E' wasn't
special back then.
Received on Sunday, 7 January 2001 03:16:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:21 UTC