No one has mentioned a dedicated XPath-Debugger that I've developed
for the last couple of years, perhaps because its not yet integrated
with an XSLT environment (though it can auto-import expressions from
XSLT, using XPath!).
This graphical tool (soon to be replaced by a tool that also
integrates with a zip-agnostic multi-threaded batch-XSLT tester) lets
the user trace through an XPath expression visually step-by-step,
predicate-by-nested/chained predicate.
It's not perfect but hopefully falls into the 'better-than-nothing'
category. It works with for, if, else, return statements reasonably
well. The user just clicks the part of the expression they're
interested in, or expands the selection to include 1 or more chained
predicates.
This tool uses Saxon, but doesn't use the Saxon trace (haven't figured
this out from Saxon.NET), instead it builds its own expression tree.
It uses this to compute a modified expression (taking into account
predicates and instance-variables) for the user-selected
sub-expression, and then feeds this 'unseen' to Saxon for
re-evaluation, the user then gets a sequence returned in a grid-view,
and, if it contains nodes, these are also highlghted in a tree-view
and text-view. XSD type-annotations are also listed for all sequence
nodes for those users (possibly not many from 20,000 odd downloads)
with a Schema-Aware copy of Saxon.
Unsurprisingly, the same method used for XPath tracing is also used to
provide intellisense in normal editing mode that is hopefully a bit
more intelligent than the norm.
Externally referenced XPath variables (and their context) are loaded
into memory and stored in XML files for reuse, but I can improve on
this for XPath 2.1, if its to have 'let' declarations (must read that
draft soon).
Given that many of the development bugs I came across in my teams main
XSLT projects were due to incorrect/untested XPath I'm surprised tools
haven't really addressed this. But I do see one problem with improved
debuggers, this would encourage use of fewer but more complex XPath
expressions within XSLT, this could be difficult for maintenance, but
that's up to the user I guess.
Phil Fearon
On Wed, Dec 16, 2009 at 9:28 PM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
Does Saxon really provide enough data via its debugging API
to support such debugging?
Yes. If you compile the stylesheet with tracing enabled, Saxon wraps a trace
expression around every node in the expression tree, and each one results in
a pair of enter() and leave() calls to the TraceListener.
The problem of course is that if you exposed this granularity in a debugger,
the steps would be so small as to make single-stepping extremely tedious. So
the debugger has to choose which calls to ignore. I don't know how oXygen
does this. I suspect it's doing the same as the Saxon XSLTTraceListener does
when you use the -T option, which is more-or-less to ignore all events other
than those associated with expressions that are classified as XSLT
instructions.
At present I can't quite see how it distinguishes between an xsl:if, and
xsl:choose, and an XPath if (perhaps it doesn't). They all produce very
similar code but there may be some provenance information retained to make
error reports more readable.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--