I know that you care and and that you put the extensions in, in the first
place, for good reasons. I also understand the weight of the work
involved. That is why a bit of motivation in dark times is often
Extensions like assign are counter-architectural in a way, a bit like
using a bottom-up approach in a top-down design maybe? or maybe the
(greater) paradigm is still not complete just by itself and needs its
(smaller) opposite to be whole?
In any case,
Thank you very much.
At 18:34 2005-06-14, you wrote:
OK, thanks for the input!
It would have gone long ago if
I weren't concerned about issues like the ones you raise.
This is always the trouble with
things that are counter-architectural - they come back to haunt you, but
they can be d----d useful in the meantime.
mailto:firstname.lastname@example.org] On Behalf Of Andre
- Sent: 14 June 2005 23:13
- To: email@example.com
- Subject: RE: [saxon] Template recursion, StackOverflowError,
saxon:while and variable assignability
- I understand your issues but there are a few cases that cannot be
resolved without saxon:assign and just as much as we try to avoid it with
everything we can, sometimes there are just no reasonable
alternatives. For those, if you remove saxon:assign, XSLT will not
be a viable solution anymore. Projects (and companies) may also go
out of business. We have already invested about 15 man/years of
development over a 5 years period and we think that this is a serious
issue. Please reconsider the options before you remove
- In fact, there is still a very limited set of indispensable saxon
extensions that should be added to the standard and the 2 main ones are
eval/evaluate and assign/assignable.
- Of course we recognize that this is your exclusive right and that you
can not be responsible for consequences of changes, especially on
extensions. We have always, and still plan to, agree and follow
your changes and upgrades but we would have made a bad choice of
technologies if we where to go out of business because this new
technology has to lose strategic functionality to evolve. Unless,
of course, there was a viable alternative for every case there is or at
least that we have.
- Would you remove assign for both versions of Saxon ?
- Saxon is a great and unique software and development tool and still
the only XSLT 2.0 processor around. We thank you for it.
- Unfortunately, there are no alternatives so, we depend on it.
- Please consider, especially when Murphy teases you too insistently in
- Please tell us how we can help.
- Thank you,
- At 11:25 2005-06-14, you wrote:
- I shouldn't pursue a
saxon:assign solution. It's getting more and more difficult to keep this
instruction working as the optimizer gets cleverer, and at some stage I
will almost certainly give up the struggle.
- This "too many nested
calls" message is really just a polite way of reporting a
StackOverflowError: it means that something is recursing too deeply (and
that tail call optimization isn't dealing with it). Do you know how deep
the recursion is?
- If you can't make the
recursive call tail-recursive, then the usual remedy is to try to find a
way of doing it using divide-and-conquer recursion rather than head-tail
recursion. I'd need to see the code to advise.
- One thing that prevents
tail-call optimization kicking in is dynamic type checking of template
results. From previous specimens of your code, I think you're using
"as" attributes on xsl:template quite extensively. It might be
an idea to try removing these from the recursive templates to see what
happens. (Hint: rename the attributes as xxx:as to comment them out,
where xxx is some namespace). Alternatively, you could try replacing the
recursive template by a recursive function - this is one area where
templates and functions still behave a bit differently.
- Michael Kay
mailto:firstname.lastname@example.org] On Behalf Of Alan
- Sent: 14 June 2005 15:59
- To: email@example.com
- Subject: [saxon] Template recursion, StackOverflowError, saxon:while
and variable assignability
- I've been using Template recursion in order to iterate over the N
- of a node in a big input document, each node creating a separate
- Haven't had any problem to date, even with big files (100Mo) and
around 100 output documents.
- But I just ran into a case of "StackOverflowError":
- SXLM0001: Too many nested apply-templates calls. The stylesheet is
- Sure, it's looping, but over the nodes that I need to output, not in
- So I thought that I'd try the Saxon extensions that allow iteration,
to wit the "saxon:while"
- extension and the "saxon:assignable" attribute to
xsl:variable, along with "saxon:assign".
- I noticed that the 8.4 documentation says that
"saxon:assign" may go away in the future.
- However, in spite of repeated attempts and tweaks, I couldn't get
saxon:assign to work:
- my global variable remained a constant value:
- <xsl:variable name="topCurTradePart"
select="0" saxon:assignable="yes" />
- <saxon:while test="$topCurTradePart lt
- Note: I tried both the "select" and "expr"
attributes to saxon:assign.
- So I'm in a corner and I'm curious what I should do:
- -- Try to pursue the "saxon:assign" workaround, in the
hopes of making it work
- -- Modify a configuration (which?) in order to keep from having
StackOverFlow exception in a normal recursion.
- Thanks for pointers.