DO NOT REPLY [Bug 6255] - Xalan 2.2 mishandles result tree fragment

[bu...@apache.org]

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

Xalan 2.2 mishandles result tree fragment





------- Additional Comments From keshlam@us.ibm.com  2002-02-05 22:01 -------
Initial diagnosis

You're trying to cdr your way through a list; each stage produces a result, 
prefixes it with "3\n    " and returns it... so you're expecting a failure due 
to the whitespace.

If I rewrite that line as
  ...  
  <xsl:template name="total-numbers">
     <xsl:param name="list"/>3<xsl:variable name="wlist"
  ...  
the template returns 3NAN. So the question is, why is the value extraction from 
the stylesheet treating the newline as end-of-number rather than as a bad 
character in a number. 

I suspect this is happening because for numbers in stylesheets and text strings 
(unlike numbers read from source documents) we're using Java's string-to-double 
conversion, and it's being "helpful". If that is indeed the problem, we could 
either use an explicit algorithm such as the one we use for source docs (I hate 
having to recode this logic), or prescan the string (expensive), or see if Sun 
is willing to accept this as a JVM bug (unlikely)...