Subject: Re: [xsl] Debugging From: "Philip Fearon pgfearo@xxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 18 Aug 2014 09:49:48 -0000 |
I developed the PathEnq web app (http://www.qutoric.com/xslt/analyser/xpathtool.html) to assist with XPath debugging. This shows the evaluation result of any selected part of an XPath expression - when a suitable source XML is loaded. In truth, while it was an interesting exercise using XSLT to re-compose XPath sub-expressions, I rarely use PathEnq because it does not integrate well with my XSLT editor. Instead, I use the fn:trace() function to wrap suspicous parts of the expression. The only annoyance is that I have to remember to remove the fn:trace() function calls once debugging is complete! Phil On 15.08.2014 10:56, Michael Kay mike@xxxxxxxxxxxx wrote: > > > This raises the question, how should one approach the debugging of such > problems, other than by staring at the code until you see the light. > > It's common enough and we've all experienced it: you write a complex > expression that looks right, and it returns nothing, and you have no > clue why. > > I'd suggest the following strategy: > > 1. Add something like > > <debug><xsl:copy-of select="X"/></debug> > > where X is the offending expression > > 2. If <debug/> comes out empty, successively remove predicates and axis > steps from X starting at the right-hand end, until you get some output. > > 3. When you get some output, the last step you removed was the one that > was wrong.
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] FOP : consumption memory, Peter West lists@xxx | Thread | Re: [xsl] Debugging, Abel Braaksma (Exsel |
Re: [xsl] FOP : consumption memory, Eliot Kimber ekimber | Date | [xsl] Connected attribute rules in , Trevor Nicholls trev |
Month |