[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] Managing debug logging in complex transforms: what do people do?

Subject: [xsl] Managing debug logging in complex transforms: what do people do?
From: Eliot Kimber <ekimber@xxxxxxxxxxxx>
Date: Mon, 24 Mar 2014 12:31:07 -0500

For whatever reason I find using interactive debugging unhelpful for
debugging XSLT processing (but I couldn't code a line of Java without it).

Thus I depend very heavily on debug messages in my XSLTs. I used to just
emit messages and then comment them out or delete them when I was done,
but then I found myself recreating those messages when I had to return to
that bit of code.

Then I started using a runtime parameter to turn debugging on or off
globally and using IF checks to output my messages. But that results in a
lot of messages when you've got a lot of debug messages, most of which are
not relevant to your current problem, so back to commenting things out or
disabling the IF check (e.g., test="false() and $doDebug").

Lately I've been trying the technique of using a tunnel parameter to
communicate the debug state to each template or function, which lets me
selectively turn on debugging within a given code path, e.g.:

<!-- Global variable set from runtime parameter -->

<xsl:variable name="doDebug" as="xs:boolean"
  select="matches($debug, '(true|yes|1|on)', 'i')"

<xsl:template match="/">
  <xsl:param name="doDebug" as="xs:boolean"

   <xsl:param name="doDebug" as="xs:boolean"

<xsl:template match="foo">
  <xsl:param name="doDebug" as="xs:boolean"


Because you can shadow a parameter within a template, you can create a
doDebug variable within a template to turn debugging on or off and that
setting will propagate to the descendant templates.

This approach is working well to make it easier for me to control my
debugging dynamically and more easily focus my messaging. But it adds some
overhead to the code in that you need the debug parameter and with-param
everywhere, which isn't that big of a deal to add but still.

My question: is there a better way to do this? Am I overlooking some
feature of XSLT 2 (or 3) that would make managing debugging messages
easier? Should I step up to a more complete messaging framework that
mirrors e.g., log4j?

This is in the context of quite complex transforms with multiple phases,
lots of twisty logic, non-obvious stuff, and so on, as opposed to workaday
HTML- and FO-generation transforms, for which this level of sophistication
is not usually required.



Eliot Kimber, Owner
Contrext, LLC

Current Thread