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?
Use case:
We have often projects that transform XML valid against a certain
complex schema
into an XML valid against another potentially complex schema
Often such schemata are extensible one way or another with customisations
(compare it to XHTML1.1 eg.)
The "customer" often is a big company with many departments
or many customers are served with the same stylesheets
So, the mapping is not always 100% clear and the source schema can be
used in different flavors by the different departments
or the result expectations differ:
custom extensions overrule the generic mapping; optional attributes
in the result may or may not be required,...
I always aim for a generic base set of stylesheets
allowing one stylesheet where all the customisations are brought together
Customisations can be changed by department/customer
I myself can safely maintain and update the generic set
I usually have a main driver XSLT, and xsl:import most of the
stylesheets in there,
if I then xsl:include the customisation, the customisation will always win
I think, already mentioned, DOCBOOK stylesheets are a good example of
how it all could work
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?
Definitely not a last resort.
Most of my stylesheets are designed from the start for extensibility
and customisation.
Bearing customisation in mind from the start, generally leads to
stylesheets that are easier to extend and maintain
Consider an optional attribute in the result schema that should get
the value of an extension element (department namespace specific)
from the source.
I don't want the extension namespace to clutter my generic stylesheet.
I then make a call for a named template where the attribute should go
I put an empty named template definition in the same stylesheet
so in general no attribute gets created
In the customisation stylesheet, I put the same named template
definition optionally, but with a specific mapping according to the
departments wishes
(it will win over the other definition)
Consider I need to do that after I have rolled out to a number of
departments/customers...
The new (empty named template) and its caller have no effect on the
code base (given naming is chosen carefully)
So I can safely roll out a new version with this new customisation handle added
I have stylesheets out there that have this technique on many different layers
customisations for regional offices, then departments inside each
regional office,
or the specific XML editor used across different departments, or the
same CMS shared between regional offices
All works a charm to maintain
I can guess these different layers would be the cause for the name "onion"
And yes, small templates (and functions) are the key to make this happen
I was by the way not surprised to see that this topic has raised so
much traffic on this list... and some confusion as well.
Having had to coach teams of experienced XSLT programmers in the past,
architecting XSLT this way has often lead to discussion or misunderstanding,
so I realised pretty soon that this is a dark area for a number of
(even experienced) XSLT programmers.
--~------------------------------------------------------------------
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>
--~--