On Tue, Jul 7, 2009 at 8:39 AM, Jesper Tverskov<jesper(_at_)tverskov(_dot_)dk>
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
--~------------------------------------------------------------------
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>
--~--