Hi Jesper,
oXygen sets a trace listener on Saxon to be able to offer the "Stop
Transformation" action that allows users to stop a transformation at any
time. That causes more method calls as Saxon will call the listener on
all instructions and the transformation requires more stack memory. For
example I was able to run your transformation setting the stack for
oXygen to 10MB.
In the current development code of oXygen we found another way to
implement the "Stop Transformation" action, without setting a trace
listener on Saxon and your stylesheet works without problems with the
default stack memory.
Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
Jesper Tverskov wrote:
Hi list
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
http://www.xmlkurser.dk
http://www.xmlplease.com
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--