I'm on a high. I've been stuck with this problem of trying to understand a HUGE xslt that operates on an even bigger XML. I sorely needed something that will let me trace through the xslt execution to understand the flow.
Tried a couple of IDEs - Stylus Studio (free edition) and Marrowsoft XSelerator. Stylus studio did a graceful exit, Xselerator went purple in the face and died a gruesome death :-(
Hmm... so after sometime I was wondering if I could annotate the XSL output with information on the templates matched it would atleast help partway. I was thinking of perl/C#/regular expressions and then suddenly the penny dropped "for each xsl:template node, include a comment with the template match/mode" - Hang on!!! looks like that sounds like a job for XSLT....
Anyway, there are a couple of quirks - the first one you hit will be when you try to output a template like this
Oops! The XSLT processor cribs (and with good reason too)! It doesn't know which xsl:template is for the current stylesheet vs which is intended to be output to the result document.There are a couple of approaches around this. One is to use xsl:element like this
But this results in enormously wordy documents. Thankfully there's a neater way out. You use something called. Basically, what it does is that it allows you to use a dummy namespace in your xslt. You set up the dummy namespace (let's say genxsl) to map to a real namespace in the result document (xsl). Then you basically use the dummy namespace in your XSLT. However, when generating output, the processor will replace all references to the dummy namespace in the result document with references to the real namespace. For ex.
Note the usage of xsl:namespace-alias and the code for generating an xsl:stylesheet element in the result document.
I've included my efforts here - along with a simple books.xml, a books.xsl which generates a table and finally an instrument.xsl that instruments books.xsl to generate an instrumented version. Transforming books.xml with the instrumented xslt generates output that annotated with custom nodes that highlight which template got called when.
After I was mostly done with the code, I came across an article in IBM developerWorks which discusses the same topic. Rather than cover the same material again, you can find the article here. Stuff that's different is that I generate custom nodes (which I thought would be useful to view in XML IDE which allow a hierarchical display). I've also shamelessly borrowed the code to generate the Xpath of the node (part of what you see in the snippet).
Tried a couple of IDEs - Stylus Studio (free edition) and Marrowsoft XSelerator. Stylus studio did a graceful exit, Xselerator went purple in the face and died a gruesome death :-(
Hmm... so after sometime I was wondering if I could annotate the XSL output with information on the templates matched it would atleast help partway. I was thinking of perl/C#/regular expressions and then suddenly the penny dropped "for each xsl:template node, include a comment with the template match/mode" - Hang on!!! looks like that sounds like a job for XSLT....
Anyway, there are a couple of quirks - the first one you hit will be when you try to output a template like this
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
<xsl:template match="xsl:stylesheet" >
<!-- generate an output xsl:stylesheet node -->
<xsl:stylesheet></xsl:stylesheet>
</xsl:template>
</xsl:stylesheet>
Oops! The XSLT processor cribs (and with good reason too)! It doesn't know which xsl:template is for the current stylesheet vs which is intended to be output to the result document.There are a couple of approaches around this. One is to use xsl:element like this
<xml:namespace prefix = xsl />
<xsl:element name="xsl:template">
</xsl:element>
But this results in enormously wordy documents. Thankfully there's a neater way out. You use something called
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:gen="http://www.w3.org/1999/XSL/Transform/2">
<xsl:namespace-alias stylesheet-prefix="gen" result-prefix="xsl"/>
<xsl:template match="xsl:stylesheet">
<gen:stylesheet>
<xsl:for-each select="@*">
<xsl:attribute name="{name(.)}">
<xsl:value-of select="."/>
</xsl:attribute>
</xsl:for-each>
<xsl:apply-templates></xsl:apply-templates>
<xsl:if test="not(xsl:template[@name='pseudo-xpath-to-current-node'])" >
<xsl:text>
&#10;&#10;
</xsl:text> <xsl:copy-of select="document('')/xsl:stylesheet/xsl:template[ @name='pseudo-xpath-to-current-node']"/>
<xsl:text>
&#10;&#10;
</xsl:text>
</xsl:if>
</gen:stylesheet>
</xsl:template>
</xsl:stylesheet>
Note the usage of xsl:namespace-alias and the code for generating an xsl:stylesheet element in the result document.
I've included my efforts here - along with a simple books.xml, a books.xsl which generates a table and finally an instrument.xsl that instruments books.xsl to generate an instrumented version. Transforming books.xml with the instrumented xslt generates output that annotated with custom nodes that highlight which template got called when.
After I was mostly done with the code, I came across an article in IBM developerWorks which discusses the same topic. Rather than cover the same material again, you can find the article here. Stuff that's different is that I generate custom nodes (which I thought would be useful to view in XML IDE which allow a hierarchical display). I've also shamelessly borrowed the code to generate the Xpath of the node (part of what you see in the snippet).
