Re: [xsl] Re: Keeping a running total?

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

At 01:22 PM 7/12/2006, Ken wrote:
> Consider that, with the given design, once you implement and debug a 
> given XSLT template rule, there is nothing possible *by design of 
> the language* that would break the functioning of that template 
> rule.  I would think just that savings in debug time alone would 
> outweigh any savings in development time.

This is especially the case as documents and transformation 
requirements scale up in complexity, as stylesheets become modular, 
and as systems move towards layered mixes of off-the-shelf and custom 
stylesheets, for example those handling XML formats such as Docbook, 
TEI, ODF and what have you.

While I was never in the position of having to implement 
transformations in pre-XSLT technologies (except DSSSL, which doesn't 
count for these purposes), those who have (including Ken) can recall 
for us the pain and suffering associated with scaling, maintenance 
and reuse issues in the bad old days.

There is certainly a down side to XSLT's restrictions on variables, 
but those generally tend to be felt by newcomers to the language 
working on quick-and-dirty stylesheets, who (for whatever reasons bad 
or good) are resisting learning new ways of thinking. (Steve I'm not 
placing you in this camp; most beginners do not come straight out 
with a problem stretching so far beyond XSLT's core competency.) Once 
one has assimilated what David C has called "The XSL Way", it's 
actually easier to think and design in it than it is to compose the 
logic for procedural approaches. This is because the rules-based and 
input-driven approach of XSLT tends to mirror specifications 
themselves rather than the processes used to achieve their solutions, 
which mostly end up being the business not of the stylesheet but of 
the engine that executes it.

This is not to say that certain kinds of transformation are not be 
easier or more straightforward using another technology or 
programming paradigm. I think that will always be the case. (Yet I 
hasten to note that no one has yet suggested XSLT pipelining as an 
approach to the running-totals problem; not only would pipelining 
and/or recursion make quick work of it, I bet, but also it is a 
native technique in XSLT 2.0 -- which also does without mutable variables.)

As Ken also notes, there are also many ancillary advantages to 
side-effect-free processing, which may be unimportant to particular 
developers (like the broad availability of conformant tools in many 
flavors) but which are very much to the benefit of developers in general.

Finally, we are now at a point where we can ask Darwin to judge. If 
mutable variables are such an essential feature, would not XSLT, in 
the years since 1999, have been superceded by a transformation 
technology that included them? Maybe not, but such alternatives have 
existed and still do exist.

Cheers,
Wendell