At 2010-03-14 03:39 +0200, Jacobus Reyneke wrote:
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.
For example, what if I just quickly want to build the table of
contents, of if I just want to get certain element types, sometimes
only the structure of my XML, sometimes just the images. Things like
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
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
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
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
If, however, you had your "structure-only.xsl" stylesheet you might
have something like:
<xsl:text/>Image here: <xsl:value-of select="@fig"/>
<!--ignore the section content, just process subsections-->
<xsl:template match="list"/><!--hide all lists-->
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