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

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

Subject: Re: [xsl] Managing debug logging in complex transforms: what do people do?
From: "Imsieke, Gerrit, le-tex" <gerrit.imsieke@xxxxxxxxx>
Date: Mon, 24 Mar 2014 21:34:59 +0100

On 24.03.2014 18:31, Eliot Kimber wrote:
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.

We use (and sometimes overuse) an approach where we tackle only a specific aspect of the overall transformation in a single pass. For example, if the task was to group flat block-level HTML elements according to the heading levels and to group adjacent HTML spans / interspersed whitespace according to common formatting, you could to everything in a single pass. If memory consumption and the compute cycles for millions of identity transforms are of no concern, webd prefer separate passes, though, and write the intermediate results to a debug file for each pass. By diffing the results for two subsequent passes, or by diffing the same passes for two transforms with slightly modified settings, itbs easy to see why templates donbt match, have unwanted side-effects, etc.

We also do ad-hoc message based debugging in a similar way as you describe it. We donbt do much interactive debugging, either.

If there were interactive messages in command-line Saxon/Calabash, Ibd probably use them more often than oXygenbs debugger.

Ibm thinking of something like
<xsl:message error-code="foo" select="'foo error: ', $var"/>
(xsl:message/@error-code is standard XSLT 3.0 markup [1])

And then have a processor option where you can specify the error-codes (comma-separated EQNames [2], or #all for all named messages) of messages upon encountering which the processor will ask you interactively what to do:
b Ret: continue, stop at next message;
b b: continue b non-interactively display all following messages with the same error-code as they occur, but stop at any other error-coded message;
b s: suppress (donbt even display) all following messages with the same error-code;
b i [expr]: display (inspect) XPath expression expr (e.g., $var, current-group(), current-group()/name(), distinct-values(//*:para/@role), b&)
b b&

Would you like an XSLT 3 processor to offer this kind of interactive message support?


[1] http://www.w3.org/TR/xslt-30/#element-message
[2] http://www.w3.org/TR/xpath-30/#prod-xpath30-EQName

Current Thread