[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Debugging

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!


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