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

[Eliot Kimber <ekimber@xxxxxxxxxxxx>]

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.

E.g.:

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

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

Cheers,

E.
bbbbb
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




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

>
>
>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?
>
>Gerrit
>
>[1] http://www.w3.org/TR/xslt-30/#element-message
>[2] http://www.w3.org/TR/xpath-30/#prod-xpath30-EQName