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.
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com
On 3/24/14, 3:34 PM, "Imsieke, Gerrit, le-tex"
<gerrit(_dot_)imsieke(_at_)le-tex(_dot_)de>
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, we’d
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, it’s easy to see why templates don’t match, have
unwanted side-effects, etc.
We also do ad-hoc message based debugging in a similar way as you
describe it. We don’t do much interactive debugging, either.
If there were interactive messages in command-line Saxon/Calabash, I’d
probably use them more often than oXygen’s debugger.
I’m 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:
– Ret: continue, stop at next message;
– b: continue – non-interactively display all following messages with
the same error-code as they occur, but stop at any other error-coded
message;
– s: suppress (don’t even display) all following messages with the same
error-code;
– i [expr]: display (inspect) XPath expression expr (e.g., $var,
current-group(), current-group()/name(), distinct-values(//*:para/@role),
…)
– …
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--