Related link: http://www.cranesoftwrights.com/schedule.htm#ptux
XSLT has long been a tool I’ve used, but as little as possible. After two days of training, I’m both remembering why that is and learning ways to work around the aspects of the language that have bothered me for years. Getting a more complete understanding of XSLT’s context and intent makes a huge difference.
XSLT is, in many ways, alien territory to “classical programmers”, whether those programmers came from procedural or object-oriented styles. Variables don’t vary, but they are namespace-qualified. Whitespace doesn’t matter most of the time, but it creeps up in unexpected ways that foil seemingly obvious ways to do things. Scope issues frequently confound approaches that briefly looked promising, though recursion often holds a solution. Parentheses aren’t nearly as harmless as they are in the languages I’m used to, like Java. Meanwhile, there’s frequently more than one way to do things, and the differences, if any, are often subtle.
While this might sound daunting, it’s actually made the training a lot more interesting because of interactions you can have much more easily in person. A lot of the fun in this class has been Ken Holman’s phrasing problems in terms which make great sense to programmers, but which aren’t the best way to solve the problem in XSLT. After we visit the possibilities, we find a better answer. While much of the course is lecture, exercises and general interplay give us all (myself included) a chance to make mistakes both in private and in public. These aren’t the kinds of interactions you can have in a half-day tutorial, never mind a 45- or 90-minute presentation. By the end of this, we’ll have experienced firsthand - and solved - most of the common (and mysterious) problems that arise in XSLT development.
My fellow trainees are an interesting mix of Canadians and Americans, docheads and dataheads. Only two people (of ten) are using DTDs for their XML, but it doesn’t seem that everyone’s rushed to embrace the latest in XML technology, as almost no one is using XML namespaces in their work either. (I use them about half the time.) Some attendees have prior XSLT experience, but everyone arrived knowing XML already.
This course is explicitly about XSLT 1.0 and XPath 1.0, but XSLT 2.0 and XPath 2.0 have come up a few times. Sometimes it’s been in the context of problems which those new specs will solve better, but at least as often the future is dark, cloudy, or unclear. It’s hard to imagine covering those mammoth specifications in this kind of detail - I have a hard time imagining any but the most dedicated sitting through the ten days of training those specs would seem to demand. Larger specs create problems that go way beyond the scope of the problems they were meant to solve.
Some of Ken Holman’s choice tidbits are well worth repeating, though they may make more sense to you if you know XSLT.
“Many new users don’t realize how little XML has done. And maybe that’s why it’s so successful.” (To be fair, he meant that XML has succeeded by doing little, not that users didn’t get it.)
“// is the biggest waste of [processing] time in stylesheets… This isn’t to say that // doesn’t have a role at times.“
“Not intuitive, and not in the REC.“
Perhaps the most important quote I’ve heard from Ken, the one which most clearly tells me the boundaries where XSLT is useful or not, is:
“All we’re doing is building a result tree.“
If I have a problem I can (reasonably) describe as result-tree building, XSLT is a good candidate for the work. If that’s a stretch, there’s probably another tool that’s more appropriate. We’ll see if my brain can keep up after a few more days of this, but right now I’m very pleased with a better understanding of problems that have troubled me for years.
Ever build a result tree?