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.