[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Managing debug logging in complex transforms: what
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|