xsl-list
[Top] [All Lists]

Re: [xsl] Onion-skin overriding stylesheet

2011-09-07 07:06:45
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(_at_)CraneSoftwrights(_dot_)com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal


--~------------------------------------------------------------------
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>
--~--

<Prev in Thread] Current Thread [Next in Thread>