Re: Conditional Execution in XSLT 2.0
I'm currently writing my content in XML, while at the same time writing XSLT to transform this content into a written manual. The problem is that sometimes I just want to quickly print out part of my document using XSL-FO to PDF.
I suggest the onion-skin approach: write your core stylesheet to do *everything* in a production state, and then have a number of different onion-skin stylesheets importing your core and overriding the template rules you don't want with empty template rules or alternative renderings.
Currently I'm commenting out parts of the XSLT, but there must be a better way. Should I split my XSLT into different libraries and conditionally include them based on parameters,
There is no run-time conditional inclusion. The only conditional inclusion there works at compile time without access to passed parameters.
or should I try and set variables throughout the doc using things such as visible/invisible?
That seems a bit cumbersome as I get from your note the transient nature of these alternative selective transformations. Also, as soon as you touch already tested stylesheets, how do you know you haven't made a mistake that would be difficult to undo?
is there a tried and tested way when working with ever changing XML and XSLT while still creating and building the content and transformations?
Many new users overlook the dynamic nature of overriding templates with importing stylesheet fragments that intercept the processing of selected nodes.
I often create "editorial stylesheet" onion-skins for my customers. Such renditions augment the core rendition with additional editorial information exposed for the process of confirming the hidden content. Hand on heart I can tell them that the core behaviour for their customers is unchanged by creating the onion skin for the editors. The core stylesheets are untouched.
What I just had to do as an example, was to comment out my "body text" templates and "list templates" and "image" templates" etc, just so I could print out the document structure without any content.
But that is prone to human error and messing up core stylesheets that might have already been tested and proven, thus requiring them to be tested again.
If, however, you had your "structure-only.xsl" stylesheet you might have something like:
<xsl:stylesheet ... <xsl:import href="core.xsl"/> <xsl:template match="image"> <xsl:text/>Image here: <xsl:value-of select="@fig"/> </xsl:template> <xsl:template match="section"> <xsl:apply-templates select="title"/> <!--ignore the section content, just process subsections--> <xsl:apply-templates select="section"/> </xsl:template> <xsl:template match="list"/><!--hide all lists--> </xsl:stylesheet>
Then instantly you can either see your end-user results by running "core.xsl" or you can see your editorial results by running "structure-only.xsl" without any changes to the core. And when you do have fixes for your core, your onion-skin doesn't change.
Am I being stupid here?
I wish new users would not mistake unawareness with stupidity.
Many people with experience in other languages assume they have to do the same brute-force copy/hack/paste parallel processing, which only serves to duplicate the amount of parallel maintenance.
Consider one of my customers who took the tri-fold stylesheets I write for them and needed bi-fold geometry to be used. They had to do this without touching the original stylesheets because of their re-testing-everything-if-anything-changes rules. A new staff member with a Java background simply copied the entire chain of four or five imported stylesheets I created for them, in order to hack only four or five values in two or three templates. During the review I threw away all of the copied templates and created a "bi-fold" stylesheet that imported the "tri-fold" stylesheet, having only the two or three templates in the "bi-fold" onion-skin that overrode the corresponding templates in all parts of the chain of "tri-fold" stylesheets. Then they had exactly what they needed without touching a single byte of the "tri-fold" stylesheets, and without triggering the re-testing regime. From a maintenance perspective, in the future any changes needed in the core would be reflected in both renditions. The way the programmer had done it would have required parallel fixes and parallel tests and parallel maintenance.
In your scenario you simply have as many different onion skins as you need alternatives from the core rendering.
I hope this helps.
. . . . . . . . . . . . . . Ken
-- XSLT/XQuery training: after http://XMLPrague.cz 2010-03-15/19 XSLT/XQuery training: San Carlos, California 2010-04-26/30 Principles of XSLT for XQuery Writers: San Francisco,CA 2010-05-03 XSLT/XQuery training: Ottawa, Canada 2010-05-10/14 XSLT/XQuery/UBL/Code List training: Trondheim,Norway 2010-06-02/11 Vote for your XML training: http://www.CraneSoftwrights.com/s/i/ Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/ G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/s/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
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