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 )
And then have a processor option where you can specify the error-codes
(comma-separated EQNames , 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
b s: suppress (donbt even display) all following messages with the same
b i [expr]: display (inspect) XPath expression expr (e.g., $var,
current-group(), current-group()/name(), distinct-values(//*:para/@role), b&)
Would you like an XSLT 3 processor to offer this kind of interactive