You make some good points, unfortunately I don't have the luxury of using non
XSLT (this is one problem XML file amongst thousands of different ones that
work fine, so they won't entertain changing architecture for one corner case)
and tail recursion, because of the xml structure, is the only option.
You're point about creating a custom extension is spot on the money, and in
fact what I ended up doing yesterday :)
I created a custom extension function/element combination that works such:
<bucket:add name="nodebucketname" select="path"/>
<xsl:for-each select="bucket:retrieve('nodebucketname')">
.....do some stuff....
</xsl:for-each>
I thought this would work well, but it's giving me random ArrayIndexOutOfBounds
errors when I iterate over the bucket nodes :(
The errors are coming from DTMDefaultBase._exptype returning NULL (-1)
sporadically (I haven't been able to deduce any pattern to this behaviour). So
I'll spend some more time on it today, if not I'll just double the ram on the
processing machine and go on with life :)
Unfortunately, delving into DTMDefaultBase.java is waaaaaaay beyond my
expertise ;)
Thanks for the suggestions
--- On Tue, 21/4/09, [email protected] <[email protected]> wrote:
From: [email protected] <[email protected]>
Subject: Re: odd NodeSet behavior
To: "Adam Jenkins" <[email protected]>
Cc: [email protected]
Received: Tuesday, 21 April, 2009, 10:54 PM
> The one big draw back of XSLT is crappy recursion.
There are ways for an XSLT processor to reduce recursion overhead --
recognizing opportunities to turn tail-recursion into iteration is a big
one -- but I don't think Xalan implements much along those lines yet. Good
opportunity for someone who has time to contribute...
Sometimes restructuring a problem can reduce recursion depth.
But, yeah, sometimes the right answer is to leave XSLT. Personally, if it
needs stateful code I tend to leave XSLT entirely and hand-code the
solution, but if you're willing to take the risks... One thought: If
you've got to write stateful code, try to structure your problem so XSLT
data dependencies will keep it from being reordered.
Getting back to the problem: When we wrote the Xalan extension mechanism,
we assumed that most interaction between Xalan and the extensions would be
in terms of DOM rather than xpath types. Xalan can present a read-only DOM
view of its documents to the extensions, and knows how to access DOM
objects returned by the extensions. (See
http://xml.apache.org/xalan-j/extensions.html#ext-functions for a
description of the conversions/equivalencies.) So you might want to
consider something like having your extension accumulate its data into a
simple array of Nodes and implement a NodeIterator which scans that array
and can be treated as a nodeset by Xalan. That keeps you within Xalan's
documented-and-supported extension behaviors.
Yahoo!7 recommends that you update your browser to the new Internet
Explorer 8.Get it now.
