At 2011-09-07 10:50 +0200, Jesper Tverskov wrote:
The onion-skin overriding stylesheet that can redefine global
declarations is fascinating, and I would like to hear more about what
experience you have actually making solutions that way.
A case study I presented at a conference in 2005 is here:
http://www.cranesoftwrights.com/links/ipepaper.htm
We can customize a stylesheet with global parameters, we can have XML
config files to be loaded as part of a transformation, so when exactly
is it that the onion-skin overriding stylesheet is attractive for
customization and maintenance?
When creating a "stylesheet library" to be used by yourself or others
in different contexts. The case study regards a library of
publishing functionality that different libraries can use
"off-the-shelf" or customized through the use of the onion-skin
overrides for different appearances.
Is the onion-skin mostly something we can use as a last resort if some
unforeseen maintenance or customization need suddenly pops up, or is
it often the most attractive approach to maintenance and customization
from the beginning?
Not at all. The feature being exploited is the ability to tweak a
set of stylesheets without changing the set of
stylesheets. Maintenance is but one scenario where this is
useful. Distributing a core library for many users to exploit is but another.
As far as I know, no matter what a stylesheet looks like, we can
always import and override it in another stylesheet. But if the
original stylesheet is mostly one big template with many xsl:for-each,
we will have to recreate most of the original stylesheet in the
overriding stylesheet, and that is not that attractive.
Indeed, which is why you shouldn't design your stylesheets using such
"pull" constructs. Rather, the more you use "push" requiring
template rules to match the nodes being pushed at your stylesheet,
the more opportunities you have to tweak the behaviours of those
nodes being caught in template rules.
Only top-level constructs (immediate children of the document
element) are candidates for being overridden by <xsl:import>.
If we on the other hand use xsl:apply-templates as much as possible,
and match the input as detailed as possible, using very many
templates, if we use a lot of global variables even if only used once,
etc., etc., it is possible to override many details in a stylesheet
with just a line or two in the overriding stylesheet.
True.
And there are times when you may want to avoid such overriding when
using a stylesheet library.
One of my "stylesheet writing business rules" in my development of
stylesheets to be exploited by others is that every named top-level
construct is named with a qualified name in one of two
namespaces: the private namespace of the library the user is not
allowed to use, and the public namespace of the library the user is
allowed to use. Thus, I put protected constructs in the private
namespace, and configuration constructs in the public
namespace. Instructing users not to use the private namespace
guarantees to me that the behaviour of the library will not be
impacted negatively by the user (provided users behave themselves and
don't use the private namespace).
If I need node matching to be unaffected by users, then I match nodes
in a mode whose name is qualified with the library's private namespace.
Also if we have important functionality made with a lot of functions,
we can include the logic in named templates or in xsl:function to make
it much easier to override in the importing stylesheet.
Absolutely. For XSLT 1.0 constructs this has all been available
since 1999. This isn't new at all. When I wrote my first stylesheet
writing business rules in 2003 before presenting XSLStyle publicly at
XML'2004, I had already been following the principles for years but
never formalized them using XSLT to enforce them (since a stylesheet
is just XML).
Is the onion-skin approach to stylesheet making so attractive, that we
should make it a habit always to prepare for it, should we so to speak
"override" optimize our stylesheets to make them as easy as possible
to override (to maintain, to customize)?
I do. So much so that in my XSLStyle stylesheet documentation
business rules I enforce such properties in a stylesheet. If any
global is not in a namespace, and I haven't explicitly flagged that
global as desired to be in no namespace, the XSLStyle reporting
reports that global as an inconsistency requiring attention.
And to help identify where named globals are found in a deep
import/include hierarchy, the XSLStyle report includes an
alphabetized index at the end of each such global and in which
fragment they are declared.
One of my clients published here the XSLStyle report generated for a
stylesheet I wrote for them:
http://www.CraneSoftwrights.com/links/sportsmlt2.htm
In this library global parameters in no namespace are used for
invocation parameters. Global variables using the "ssp:" (private)
namespace are for globals I do not want end users to touch. The
global variable in the "ss:" namespace is available for end users to
change. The top of the report summarizes those variables flagged as
invocation parameters and those in the public namespace not flagged
as invocation parameters. The variables in the private namespace are
not listed (so as not to temp users who read the documentation to
invoke or tweak the stylesheet), but I can still find them in the
alphabetized index when I'm looking for them.
Note that the customer did not explicitly request such tweaking
ability, but by following my stylesheet business rules (which I do
for all customers), the end result I delivered has all of the
properties available should the customer decide at the last minute
before production or some time in the future to modify the behaviours.
I hope this is helpful.
. . . . . . . . . . Ken
--
Contact us for world-wide XML consulting and instructor-led training
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal