Re: [xml] XPath numbers and exponential notation

[Thomas Broyer <tbroyer ltgt net>]

>  Do other XPath implementations made this extension by augmenting the
> number production or by using a namespaced function ?

SAXON raises a fatal error on <xsl:value-of select="75.2E-12"/> (unexpected
token <name> beyond end of expression) but support conversion with the
number() function (<xsl:value-of select="number('75.2E-12')"/> doesn't
raise any error). However, output is "0.0000000000752" w.r.t the XPath
string() function.

Xalan-J doesn't raise any error but outputs "0.0000000000752" as expected.

This is related to Java String to double casts and don't appear in Xalan-C
(which outputs NaN in both cases).

Sablotron raises a "wrong expression syntax" error, just as SAXON, for the
first and outputs 7.52e-11 for the second (just like the actual behaviour
of libxml/libxslt). It uses sprintf("%.13g", num) for the number to string
conversion.

There isn't any consistant behaviour or even conformant one!

SAXON and Xalan-J should convert to "NaN" in the second test case. Xalan-J
and Xalan-C should raise an error in the first test case. Sablotron should
output NaN in the second test case.

I added a third test case : <xsl:value-of
select="string(0.0000000000752)"/>.
No problem for SAXON and Xalan-J (obviously). Sablotron still outputs
7.52e-11 (obviously). Xalan-C outputs "0." ?! (obviously a bug in the
number-to-string conversion)

None of these processors provide an extension function.

My view is to, at least, output (convert to string) in a non-scientific
notation (we may assume an expression doesn't contain numbers in scientific
notation, as Xalan-J does), and eventually add a flag for switching between
XPath 1.0 and partial future XPath 2.0 conformance.

Tom.