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=5142>.
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=5142

xsltc shouldn't use exponential notation for number formatting (string134)

           Summary: xsltc shouldn't use exponential notation for number
                    formatting (string134)
           Product: XalanJ2
           Version: CurrentCVS
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Minor
          Priority: Other
         Component: org.apache.xalan.xsltc
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


Morten said: Number formatting is described in the XSLT 1.0 spec's section 4.2 
(on the 'String' function): 

   "[...]otherwise (if the number is not 0, not NaN, not Infinity and not an 
   integer), the number is represented in decimal 
   form as a Number including a decimal point with at least one digit 
   before the decimal point and at least one digit after the decimal point, 
   preceded by a minus sign (-) if the number is negative; there must be no 
   leading zeros before the decimal point apart possibly from the one required 
   digit immediately before the decimal point; beyond the one required 
   digit after the decimal point there must be as many, but only as many, more 
   digits as are needed to uniquely distinguish the number from all other 
   IEEE 754 numeric values.[...]". 

This does say more digits as are needed, so I take that as an indication that 
exponential notation is not allowed. A reference is also made to IEEE 754, 
but IEEE 754 is not a description of a notation, but a specification on how to 
make binary representations of decimal real numbers and fraction. Exponential 
notation is used in the IEEE 754 specs, but this is of no importance in this
case. 

Here's a comparison of Xalan and XSLTC on string134 showing the problem:

Running xalan on string134
<?xml version="1.0" encoding="UTF-8"?>
<out>Positive numbers:
9.87654321012345,98.7654321012345,987.654321012345,9876.54321012345
98765.4321012345,987654.321012345,9876543.21012345,98765432.1012345
987654321.012345,9876543210.12345,98765432101.2345,987654321012.345
9876543210123.45,98765432101234.5
Negative numbers:
-9.87654321012345,-98.7654321012345,-987.654321012345,-9876.54321012345
-98765.4321012345,-987654.321012345,-9876543.21012345,-98765432.1012345
-987654321.012345,-9876543210.12345,-98765432101.2345,-987654321012.345
-9876543210123.45,-98765432101234.5
</out>


Running XSLTC with Xerces Parser on string134
<?xml version="1.0" encoding="UTF-8" ?>
<out>Positive numbers:
9.87654321012345,98.7654321012345,987.654321012345,9876.54321012345
98765.4321012345,987654.321012345,9876543.21012345,9.87654321012345E7
9.87654321012345E8,9.87654321012345E9,9.87654321012345E10,9.87654321012345E11
9.87654321012345E12,9.87654321012345E13
Negative numbers:
-9.87654321012345,-98.7654321012345,-987.654321012345,-9876.54321012345
-98765.4321012345,-987654.321012345,-9876543.21012345,-9.87654321012345E7
-9.87654321012345E8,-9.87654321012345E9,-9.87654321012345E10,-9.87654321012345E11
-9.87654321012345E12,-9.87654321012345E13
</out>

Reply via email to