[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Managing debug logging in complex transforms: what

Subject: Re: 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
Re:  Managing debug logging in complex transforms: what
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

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.