You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by bu...@apache.org on 2001/10/17 15:58:17 UTC

DO NOT REPLY [Bug 4219] - number('+30E-1') returns 'NaN' instead of '3'

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

number('+30E-1') returns 'NaN' instead of '3'





------- Additional Comments From keshlam@us.ibm.com  2001-10-17 06:58 -------
Worked in the past because we were using Java's string-to-double conversion, 
which supports this... so the old behavior was really a 'useful bug' rather 
than a deliberate feature. Doesn't work now that we're using our own version of 
that algorithm (see recent change to XStringForFSB).

Could add it. But I'm always nervous about adding extensions to the XSLT 
language, since they encourage folks to write stylesheets that won't port to 
other environments. 

So I think my on preference would be to tell folks to use an explicit extension 
function for scientific-notation support, so they're aware they're stepping 
outside the pale... and so they can add the same extension to other processors 
to get comparable results.

In any case, I'd suggest switching the severity from BLOCKER to EXTENSION, since 
we never promised this would work and that workaround is available.