The core issue behind this bug relates to some type of internal difference
between the results of a select and a copy-of relative to variable
assignment. The following works with our extension function, and, as
expected passed a properly populated NodeList to the extension function:
<xsl:variable name="Values" select="/Rowsets/Rowset/Row"/>
<xsl:variable name="SPCResults" select="java:LHSPC.XIR($Values)"/>
The following, however, did not work as expected (although it worked with
versions prior to D10):
<xsl:variable name="Values"><xsl:copy-of
select="/Rowsets/Rowset/Row"/></xsl:variable>
<xsl:variable name="SPCResults" select="java:LHSPC.XIR($Values)"/>
In the latter case, a NodeList contain a single Document node appears to be
passed to the extension function.
Hope this helps pinpoint the problem!
Regards,
Rick Bullotta
CTO
Lighthammer Software
-----Original Message-----
From: Rick Bullotta [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 18, 2001 9:31 AM
To: [EMAIL PROTECTED]
Subject: RE: Extension Function Problem/Incompatible
DocumentFragmentImpl implementations?
We'll be working on it today with a simpler example and some trace code to
help troubleshoot the NodeList/extension issue. We'll keep ya posted!
Regarding your question, it was "right before" and is wrong now. The Xpath
expression used to generate the NodeList passed into the extension function
would return 19 Element nodes. It appears that the current build (D10)
passes in a single Document node. As soon as we have more specifics, I'll
pass 'em along.
Thanks.
- Rick
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 18, 2001 9:22 AM
To: [EMAIL PROTECTED]
Subject: RE: Extension Function Problem/Incompatible
DocumentFragmentImpl implementations?
>unfortunately, the NodeList is garbage (getLength() returns only one node,
>instead of the 19 expected).
Without seeing an example, it's hard to be sure whether the NodeList is
wrong now, or was wrong before...
