DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23064>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23064 The format-number() Function [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID ------- Additional Comments From [EMAIL PROTECTED] 2003-09-17 21:42 ------- I think Xalan-J 2.0.0 had a bug. As Joanne pointed out, the syntax for a number in XPath 1.0 doesn't permit "E" notation.[1] Further, when the type of an argument is expected to be of type number, the argument is converted as if by the number function.[2] According to the description of the number function [3], "a string that consists of optional whitespace followed by an optional minus sign followed by a Number followed by whitespace is converted to the IEEE 754 number that is nearest (according to the IEEE 754 round-to-nearest rule) to the mathematical value represented by the string; any other string is converted to NaN." So, a string value like "2.090699555E7", when converted to a number using the number function, explicitly or implicitly, has the value NaN. If you require other syntactic forms for numbers, you might be able to use a Java extension, or write a template that parses the value as Joanne described. I hope that helps. [1] http://www.w3.org/TR/xpath#NT-Number [2] http://www.w3.org/TR/xpath#section-Function-Calls [3] http://www.w3.org/TR/xpath#function-number
