[xsl] Stepping through XPath in a visual XPath debugger

Subject: [xsl] Stepping through XPath in a visual XPath debugger
From: "Philip Fearon" <pgfearo@xxxxxxxxxxxxxx>
Date: Tue, 31 Jul 2007 17:51:06 +0100
Hi

I would be grateful for any views from this list on how best to
implement an XPath 1.0 step-through debugging facility.

Some context:
I'm developing this for a relatively small (less than 15,000 lines of
c#) personal freeware project. A 2 month public beta test has not yet
produced responses that helps me with this debugging issue. The .NET
2.0 XPath implementation is currently used for XPath evaluation,
though Saxon.Net is an obvious candidate for a future XPath 2.0
upgrade.

There are quite a few issues that stepping through XPath raises, but
my key questions are:

a) What is the most intuitive order in which to step-through an XPath
1.0 expression visually?
b) Which 'steps', if any, can be left out - to avoid annoying clutter?
c) Is it ok to just go 'left to right' or is 'step-into/over/out'
preferred for predicates and functions?
d) Should sub-expressions enclosed within parenthesis count as a
separate visible step?
e) Would the same step order be applicable for XPath 2.0?

For an example, the composability of XPath makes things awkward, but
taking a sample (made up) expression, that returns a nodeset:

abc[position() < (count(/doc/qrt[5]) + substring(child::ert[3],1,4)) -
rty][@try = $nit]

In the current early beta (read 'slightly buggy') implementation, the
application steps through in the following order (comments are shown
as: '<<comment>>'):

1. abc
2. abc[position() < (count(/doc/qrt[5]) + substring(child::ert[3],1,4)) - rty]
3. abc[position() < (count(/doc/qrt[5]) +
substring(child::ert[3],1,4)) - rty][@try = $nit] <<include chained
predicates first before stepping into nested ones?>>
4. position() <<omit or use alternative?>>
5. count(/doc/qrt[5])
6. /doc
7. /doc/qrt
8. /doc/qrt[5]
9. substring(abc/child::ert[3],1,4)
10. abc/child::node() <<node() node-test added to make this valid>>
11. abc/child::ert
12. abc/child::ert[3]
13. abc/rty
14. abc[position() < (count(/doc/qrt[5]) +
substring(child::ert[3],1,4)) - rty]/@try
15. $nit <<XSLT-style variables>>

Finally, I know there may be some argument about whether there is any
need for such a feature in a tool, but I've avoided posing this
question. My defense would be that most of the logic is required for
auto-completion of XPath expressions against an XML instance anyway
(which other tools provide), so why not?

Thanks

Phil Fearon
http://www.sketchpath.com/

Current Thread