Project

Profile

Help

Forums » Help »

Help needed to enhance Saxon debugging capabi

Added by Anonymous over 14 years ago

Legacy ID: #8244278 Legacy Poster: Gabor Guta (gguta)

Dear Mr. Kay, I'm a PhD student and I have to do some kind of visualization of an XSLT. I had positive experience with Saxon-B, so I have chosen the current version of Saxon-HE 9. I ask for some hint on how to extract the following data: a) the AST representation of the XSLT. I have to know the position of the elements in the source XSLT (line/column; may be offset and length would be nice). b) the trace of the execution of the XSLT with the output (if any) of the executed element. It is important that I have to identify the the element of the trace in the AST. So far, I have managed to build the saxon-HE from the SVN repository (it was not quite trivial...). I read your article at http://www.ibm.com/developerworks/library/x-xslt2/ and spent one day by browsing saxon source code. Are there any other sources of information worth to check? My questions are the followings: - In which part of the code it make sense to take over the AST. I haven't found a public API function to do that. The connection between XSLStylesheet (net.sf.saxon.style) and PreparedStylesheet (net.sf.saxon.style) was also not quite clear to me (and which one fits better to my needs). - I have found that I need some modification around the following code in the TraceWrapper to get the output: if (controller.isTracing()) { listener.enter(getInstructionInfo(), context); } child.process(context); if (controller.isTracing()) { listener.leave(getInstructionInfo()); } I have to record to a buffer the output in the child.process() call and than I can pass the information to the leave callback. Do you think that this is the right approach? Thanks in advance for your help!


Replies (1)

RE: Help needed to enhance Saxon debugging capabi - Added by Anonymous over 14 years ago

Legacy ID: #8244710 Legacy Poster: Michael Kay (mhkay)

(1) Sources of information. I think you have to go with the primary source, which is the code itself. (2) Static information about the AST. I assume you're familiar with the output of the -explain option on the command line, and you're presumably looking for more detail than this provides? I would suggest start by understanding how this output is produced and then look for ways of enhancing it. It would probably useful if each expression, when it calls startElement() on the ExpressionPresenter, also supplied "this" as an extra parameter, so that a subclass of ExpressionPresenter could obtain additional information about the expression being processed. (3) Dynamic trace information. I'm not sure why you have had problems with this. If I were redesigning it I would probably get rid of the InstructionInfo interface, and just pass the Expression object itself to the TraceListener. But part of the idea was for the InstructionInfo, in the case of XSLT instructions, to give access to the actual source stylesheet tree (in many cases it is actually a StyleElement). I agree it's confusing to work out what is in the XSLStylesheet, what in the PreparedStylesheet, and what in the Executable. The XSLStylesheet exists only transiently during stylesheet compilation; it is not present in the code used at run-time unless you compile with tracing enabled. The PreparedStylesheet and the Executable are both built at compile-time and continue to exist at run-time; the difference between them is primarily that the PreparedStylesheet is specific to XSLT, whereas the Executable also exists for XPath and XQuery. (So why does the Executable contain some things that are XSLT-specific, like the reference to the RuleManager? These things happen!)

    (1-1/1)

    Please register to reply