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(_at_)saxonica(_dot_)com 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.
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--