Re: Rescuing XSLT from Niche Status

> You may find that the utility of the pull approach quickly fades,
> especially in publishing solutions (though probably not as quickly in data
> solutions).  Of course the "pull" approach is untenable when dealing with
> mixed content.

This a common theme I've seen from a number of responses.  While I would
probably agree with your statement in the publishing arena, I'm not
convinced that it does not scale for data solutions (which is my admitted
focus and bias).  It is very easy to introduce additional templates and use
them with <xsl:call-template> or <xsl:apply-template> as the appropriate
need arises.  I don't see this methodology running out of gas.  Maybe the
misunderstanding is that people feel I am advocating the exclusive use of
"pull" techniques, I am not.  Instead I am proposing that "pull" techniques
be used as the entry way and then it is very easy to gradually introduce
various "push" techniques to enhance "pull"s capabilities.

> Using "pull" approaches inhibit the sharing of stylesheet fragments.  When
> an organization views the deployment of stylesheets from many
contributors,
> it is critical to be able to share stylesheet fragments.  Stylesheets
using
> the "pull" approach you are advocating are monolithic, they inhibit
> sharing, and they cannot be specialized using importation.  Stylesheets
> using the "push" approach are granular and promote reuse of the investment
> in stylesheet fragments.  Organizations should be cognizant of issues of
> stylesheet maintenance in the long term.

While I agree that the most stylesheets produced this way do not lend
themselves to being reused by others, I would argue that this is the case
for most user's code regardless of methodology unless they have substantial
experience in writing in clean modular way.  If a user wants their
stylesheet to be specializable they can move sections (that they want to be
specializable) into templates that are then called using <xsl:call-template>
or <xsl:apply-template> depending on the desired effect.  This way the
stylesheet could be imported and then have sections overridden.  I agree
this is less flexible than when everything is done via push and you can
override anything, but sometimes it is a good thing to be able to constrain
what can be overridden.

I see it as much more likely that an organization would have a few smart
people who would create components that the less capable users could draw on
through imports and includes.

Just to make sure its clear to everyone.  I'm not saying "push" is bad, I'm
just saying from an advocacy standpoint the learning curve is less steep and
smoother if learned first from the "pull" perspective.

David



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list