Permit me to offer a hearty and enthusiastic second (third?) to this motion.
I don't know if the processing model would support it, but I have
sometimes really wanted a "mode-history()", too, all the modes that have
been involved the matches that got to this template, so I can see four
matches back where the supposedly continuous chain of special-case modes
leaked out to default and caused all this trouble.
On Mon, Mar 24, 2014 at 09:50:53PM +0100, Imsieke, Gerrit, le-tex scripsit:
+1 for an XSLT function current-mode()
On 24.03.2014 21:46, Eliot Kimber wrote:
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
--~------------------------------------------------------------------
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>
--~--