Forum OpenACS Q&A: Response to Utility of XSLT?

Collapse
Posted by Stephen van Egmond on
At work, I'm developing a system that uses XSLT and XML (in this case, using Perl and Apache using the AxKit XML processor). So far, it kind of looks okay, but there hasn't been any big-bang improvements in productivity, or "phew, I'm glad we're using XSL" moments.

XML/XSL looks great in theory: look, this is how you format a phone book entry. Look: a book. Look: a list of books. Notice how there is a distinct lack of dynamic information there. How do you generate a list of books from an RDBMS? The last I saw, the ACS 4.6/5 design calls for generating DOM trees "by hand". Oh, the humanity...

When it comes to form handling, XML/XSL is pretty much a disaster. It's difficult to achieve a separation of concerns: programmer needs vs. designers' needs. How do you represent the pageflow? How do you represent the validation? What about forms that have multiple targets? How do you cram the form variables into your procedural language, and ultimately the DB? These are sticky, nasty issues that most shiny happy XSLT tutorials don't get around to even looking at. We're trying to deal with them, but even using a flexible language like Perl, it's still a challenge. We've come up with a good approach to the impedance mismatch problem between XML and set-oriented RDBMS.

Other random complaints:

  1. Tool support for designers using XSL is pathetic.
  2. To most designers, the syntax defies explanation and understanding.
  3. The designers of the w3c spec should have exercised more restraint: it's too large, written in a very opaque style, and mixes trivial, unimportant details with things that you'll end up using every day. Just look at where they describe apply-templates.
  4. XML databases are, and appear to be fated to continue to be, sad and inefficient.