[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: Eliot Kimber <ekimber@xxxxxxxxxxxx>
Date: Mon, 24 Mar 2014 15:46:15 -0500

I'll have to think about the details of <xsl:message> more before I can
answer the XSLT 3 requirements question.

But something I'd really like is a way to get the current mode name so I
can put it in the message, without having to pass it as a second debugging
tunnel parameter.


<xsl:template mode="#all" match="*">
  <xsl:message> + [DEBUG] {$modeName}: Unhandled element <xsl:value-of
select="concat(name(..), '/', name(.))"/></xsl:message>

Where here "{$modeName}" is a placeholder for some way to reflect the
current mode.


Eliot Kimber, Owner
Contrext, LLC

On 3/24/14, 3:34 PM, "Imsieke, Gerrit, le-tex" <gerrit.imsieke@xxxxxxxxx>

>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
>> HTML- and FO-generation transforms, for which this level of
>> 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
>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 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