Subject: Re: [xsl] Maximum recursion depth exceeded From: bryan rasmussen <rasmussen.bryan@xxxxxxxxx> Date: Tue, 7 Jul 2009 09:47:12 +0200 |
On Tue, Jul 7, 2009 at 8:39 AM, Jesper Tverskov<jesper@xxxxxxxxxxx> 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. > I don't know if you can say it is a bug that maximum recursion depth was exceeded, that is just an implementation limitation that should be noted. > _ _ _ _ _ > > > 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. Maybe it should give you the opportunity to disable debugging. so if disable debugging enable optimizer. Sounds like that's something they should handle. :) > > 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? > Well I guess the thing is - how many 'ways' are there to implement transformations in .NET and Java (Saxon obviously only uses one particular way) which editors wrap what command line tools which editors allow you to swap out processors. Do the processors behave differently in a commandline version... I'm probably being unclear here but let me give as an example .NET. .NET has an api for doing transformations, you have different ways to send XML input to the transformation that you programmatically determine. In a commandline app using the .NET apis you would, as a general rule, have the writer of the app determine what functionalities of the api to use and how to feed it XML input. System.XML.XSL doesn't behave differently in a commandline app, the commandline app - just like an XML Editing application - has to make decisions as to what to do with the various functionalities that it has available to it - for example does it allow the document function(), probably and so would the editor but an online transformer that took user XSLTs might not, does it allow validation of the input XML - probably turned off by default but maybe can do that based on command line parameter whereas the XML editor might have it turned on all the time and require you to go through hell to turn it off... So the commandline tools functionality does not directly map to the underlying capabilities of System.XML.XSL just as the editor doesn't. Actually now I'm starting to run on here but I think the question above: " 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? " is wrong in some way, probably someone smarter than me could identify better what I am seeing as a logical divide.. anyway, recursion problems are likely to be a problem in .NET / C#, as far as I know currently the only .NET language that can compile and optimize for tail recursion is F#.. Mvh, Bryan Rasmussen
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Maximum recursion depth excee, Jesper Tverskov | Thread | RE: [xsl] Maximum recursion depth e, Michael Kay |
[xsl] Maximum recursion depth excee, Jesper Tverskov | Date | RE: [xsl] Maximum recursion depth e, Michael Kay |
Month |