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 [EMAIL PROTECTED] 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)...
