Re: [xsl] [OT] [xslt 2.0] Difference betwen functions and templates

Subject: Re: [xsl] [OT] [xslt 2.0] Difference betwen functions and templates
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Fri, 20 Jul 2007 11:53:08 -0400

At 04:59 AM 7/20/2007, you wrote:
Just as I didn't get functional programming for a long time, there are
many people who just do not get XSLT. It is a very special language
and, serendipitously, it is turning out to be capable of solving a classes of problems in domains which were never even though of when it
was first designed. Remember Windows 1.0. That was not very
successful. Remember Windows 3.0. Different story altogether.
The difference in maturity between between XSLT 1.0 and 2.0 is similar.
Despite still having some of difficulties I raised, the future is bright for XSLT 2.0 as the tools and techniques for using it mature.

I agree with this entirely -- indeed, in just a couple of weeks I'll be demonstrating what I hope will (eventually) be a "serious" application. It's implemented with an XSLT 2.0 pipeline; I shrink from imagining it in XSLT 1.0.

(For those who haven't already recognized it, this is of course yet another plug for Extreme Markup Languages 2007, and specifically for this year's splendiferous Overlap Day on Monday Aug 6 in Montreal -- see

On the other hand, as a serious user who nonetheless works daily with others who, although they are similarly serious about their work, have even less grasp of the deeper concepts underlying the language than I do myself, I am extremely sensitive to the need for these principles, programs, systems and application architectures to be *intelligible* even to those who do not, perhaps, have advanced degrees in mathematics or computer science.

Back when XML was being formulated, this constituency was identified by the label "Desperate Perl Hacker" (DPH), since this was the state of the art of text processing in the wild in 1997 or so. While the DPH is no longer high on the list of people to think about when engineering XML systems, the fact is that despite a few bizarre wrinkles, as a markup language and data-processing technology, XML is quite simple, straightforward and approachable, and this is due in great part to this early concern.

Now the DPH may be an HTML/CSS/Javascript hacker or a desk-top publishing specialist, but he or she is still going to be a smart person who nonetheless is mystified by the deeper arcana of functional languages or OO modeling; those people are still out there and indeed still among us, and will remain so.

It seems to me that engineering will always present a tradeoff in the requirements collision between designing, building and operating a beautiful but obscure black box that somehow magically works, and fixing up and running a machine that you know how to get your hands into and even adapt to new tasks.

Because XSLT 2.0 is immensely more capable than 1.0, I expect we'll see a greater range in XSLT applications going further to both extremes. Some XSLT 2.0 will be more or less XSLT 1.0, only constructed even more simply and elegantly by using the native grouping constructs, pipelining, an occasional function, and the capability for some upconversion here and there. Other XSLT 2.0 will be something altogether different, more powerful and more awesome, but approachable only by cognoscenti.

Then there will be that snarl of spaghetti code in the middle. For me, the light dawned when I realized that the more successful a technology becomes, the more applications will be around that are poorly thought out, poorly built, and need fixing, either soon or right away. They may "do the job", but they're hardly "green", requiring constant upkeep and incurring hidden costs while they belch out pollutants that have to be cleaned up.

This brings me to being concerned with the general level of XSLT all along the spectrum, from the heavy-duty industrial-grade applications all the way down to the mom-and-pop document-processing workflows and single-shot one-offs. The former is important, but it's not the only important thing.

One of the great things about this list is that the beginners can rub up against the deep thinkers, getting a bit of wizard dust on their shirts and in their noses. We keep the culture vital by encouraging the wizards, but also those who aren't so well schooled in the dark arts -- who aren't and never will be, because they haven't the time, patience or penchant, or have other responsibilities -- or who aren't yet wizards, but soon enough will be.


Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.      
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

Current Thread