Subject: Re: [xsl] Maximum recursion depth exceeded|
From: George Cristian Bina <george@xxxxxxxxxxxxx>
Date: Tue, 07 Jul 2009 11:36:43 +0300
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
When preparing for my article, "Google's Writely and XSLT for web pages", http://www.xmlplease.com/writely2xhtml, basically a writely2xhtml transformation, using David Carlisle's htmlparse.xsl, http://dpcarlisle.blogspot.com/2007/04/htmlparse-updated.html, to do an important part of the job, I have experienced an interesting problem.
The transformation goes well with Saxon at the command line and from inside .net but fails from inside XML Editors like Oxygen and Stylus Studio. It also fails from inside XMLSpy using AltovaXML.
The XML editors return an error message saying something like "Maximum recursion depth exceeded" or "too many nested function calls". I have filed this "bug" at the three XML Editors.
_ _ _ _ _
Tony Lavinio in the Stylus Studio Forum has given this great explanation:
"The difference is most likely coming from the optimizer.
When you run Saxon within Stylus Studio (or Oxygen), in order to provide debugging support we disable the optimizer. The Saxon optimizer will reorder code, eliminate variables, and push expressions up or down the stack. It also controls tail-call recursion.
If we didn't disable the optimizer while within the IDE, there is no way you could follow the code, since the executable path doesn't really look like the source document anymore.
When run outside an IDE, optimization is enabled.
You could try using smaller input sets while within the IDE environment, but this is part of the cost of using a high-level language with a clever optimizer."
_ _ _ _ _
It is interesting to note that my test documents failing in the XML Editors still work when made 10 times longer at command line and from inside .net.
Now my question to the XSL list:
Is the above problem the one and only exception or do we have other situations where a transformation in an XML Editor is likely to fail even when the same transformation works well at the command line or from inside .net or java?
Cheers, Jesper Tverskov