Justin,
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 http://extrememarkup.com/.)
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.
Cheers,
Wendell
======================================================================
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
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
======================================================================