RE: [xsl] Onion-skin overriding stylesheet

["Echlin, Robert" <Robert.Echlin@xxxxxxxxxxxxx>]

Hi Ken,
Thanks for this, and thanks to everyone posting on this topic and on this
list.
I am maintaining and extending a publishing system that Mark Baker wrote at
Wind River in the onion skin style.
Your examples help me write code.
Your comments will help me champion a powerful, flexible system.

That's "Mark Baker" of http://analecta.com/ and http://everypageispageone.com/
- apparently there are several Marks of the Baker clan in XML or related
areas.

Rob

> -----Original Message-----
> From: G. Ken Holman [mailto:gkholman@xxxxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, September 07, 2011 8:05 AM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [xsl] Onion-skin overriding stylesheet
>
> 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