Subject: RE: [xsl] Stepping through XPath in a visual XPath debugger From: "Philip Fearon" <pgfearo@xxxxxxxxxxxxxx> Date: Tue, 7 Aug 2007 10:26:17 +0100 |
Hi An update on my initial query regarding XPath debugging: Michael Kay Wrote: >Date: Tue, 31 Jul 2007 18:08:26 +0100 >To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx> >From: "Michael Kay" <mike@xxxxxxxxxxxx> >Subject: RE: [xsl] Stepping through XPath in a visual XPath debugger >Message-ID: <014201c7d395$69196bd0$6401a8c0@turtle> > >> >> a) What is the most intuitive order in which to step-through >> an XPath 1.0 expression visually? > >I really don't know the answer to this, but I think anything that presents a >view of the evaluation as a sequential process is misleading and likely to >be unhelpful. The concept should be to select parts of the expression and >understand what contribution they make to the result - for example, being >able to see which nodes a particular predicate is applied to, and which of >them match. >Michael Kay >http://www.saxonica.com/ Wendell Piez Wrote: >Date: Tue, 31 Jul 2007 15:33:23 -0400 >To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx >From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> >Subject: RE: [xsl] Stepping through XPath in a visual XPath debugger >Message-ID:<20070731153834.GA59777@xxxxxxxxxxxxxxxxxxxxx> ... >While admitting, in sympathy with this caution, that it is an >academic exercise to view the evaluation of an XPath expression >sequentially, it might be helpful to see how we've learned to teach >neophytes to interpret XPath 1.0 location paths: > >1. The concept of a step, each step being evaluated from the context >of the previous step >2. Anatomy of a step: > 2a Axis (required) > 2b Node test (required) > 2c Predicate(s) (optional) >3. Axes in detail >4. Node tests in detail >5. Predicates (as filters of sets of nodes) >6. Abbreviations (or, short vs long syntax) ... I've updated my project now to take these views into account, this effectively leads to a form of 'hybrid' user interface for analysing XPath expressions: Random Access: Any location-step, axis, node-test, function or abbreviation can be selected by clicking on it within an expression. Sequential: To see the result of an adjacent predicate(s), or simply to move along a location-path, the cursor keys or a horizontal 'trackbar' are used. There is no obvious switching between these two modes, the 'trackbar' can be moved or a part selected with the mouse interchangeably. (In fact, when you randomly access a part, the 'trackbar' pointer moves also) To add clarity for either access mode, the selected part is highlighted and a valid XPath expression for this is extracted, colorized and displayed, taking into account the context of its position within predicates or functions. Hopefully this combination meets most debugging needs without misrepresenting what is actually happening within the expression? (Below is for info - at risk of straying off-topic but included for completeness) The XPath 'results' of selecting an expression part are shown in 5 dynamically linked panes: 1. A sortable results grid, showing node name, value, type, element position and nodeset position. 2. An element tree view with 'hits' expanded to and highlighted 3. The colorized/indented raw XML view, with the first 'hit' selected 4. A 'node list' showing the composition of the first element 'hit' (if any) 5. 'Source Nodes' Shows a list of all other available elements/attributes in 'context' at a specific part of a location step This is hard to describe completely here, but this can all be seen 'live' in action, in the project beta (SketchPath) downloadable from my website. Thanks Phil Fearon http://www.sketchpath.com/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Stepping through XPath in, Wendell Piez | Thread | [xsl] Accessing attribute in a vari, Wasiq Shaikh |
Re: [xsl] Question about XSLTC, David Carlisle | Date | Re: [xsl] translate to XML using XS, Florent Georges |
Month |