Re: Debugging (was: template matching on text value of

Reminds me of a preprocessor debugging transform I wrote/used a while
back... it would insert xsl:attribute elements in front of
apply-templates and for-each elements.. that attribute would be named
by the generate-id and copy the @select, but wrap a count() around it.

This worked with that way I was doing stuff at the time, which was a
pipeline of transforms based on the identity transform where I was
almost always in the context of creating a new element/xsl:copy and
generally only processed children once (and that xslt1 restriction on
when we can create attributes)

When I'd get errors at the end of the pipeline, those counts were the
first things I looked at.

Boy it'd be nice to work in xslt for my day-job again. :)

On Fri, Aug 15, 2014 at 1:56 AM, Michael Kay mike@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> 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.
>
>
> Michael Kay
> Saxonica
> mike@xxxxxxxxxxxx
> +44 (0) 118 946 5893
>
>
>
>
> On 14 Aug 2014, at 23:28, Ihe Onwuka ihe.onwuka@xxxxxxxxx
> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Lord.... even after staring at the shorter version  multiple times I did not
> see it. It's obviously been a long long day and I should have walked away
> from this ages ago.
>
>
> XSL-List info and archive
> EasyUnsubscribe (by email)