Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Keeping a running total?
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
