XSL is an Ugly, Difficult Language
May 20, 1999
XSL is DSSSL in sheep's clothing, an SGML transformation and formatting language that an ISO committee worked on for eight years, producing finally a language specification and an utterly heroic and breathtaking but incomplete implementation by James Clark that years of real world experience has shown to be incomprehensible and unusable to nearly everyone in the document transformation and formatting business. XSL is DSSSL, it is 100% DSSSL concepts and processing model, with some syntax changes and some attempt to merge with CSS.
I can't back up my assertion with numbers but I personally have written hundreds of transformation applications and have used nearly every tool and language in this area, DSSSL included. It is truly a tiny handful of people who have been able to master DSSSL concepts and fewer still that have been able to get it to work on a real world project. I am one of those people and I happened to have the opportunity to write such a real world application in both DSSSL and one of the popular commercial transformation languages, Balise. The DSSSL implementation took me two full weeks, Balise two days. I am qualified to give an expert opinion in this area and my opinion is that DSSSL and XSL are hard!
This is important because of the following assertion, which comes repeatedly from the XSL camp: XSL will make life easier for web developers because they will not have to write programs to perform complex document transformations. You see, XSL is not a "programming" language but a "declarative" language. XSL declarations don't do anything, they describe the state of the transformed document in relation to the original document.
It is a fascinating and lovely idea. The problem is that real-world transformations are hard, full of tricky stuff and zillions of little details such that an overly simple model of how to do or declare it quickly breaks down and becomes infinitely harder than the programming model with its many features for managing complex tasks.
I know I am not going to convince anyone that doesn't want to program to become a programmer, but I hope to convince at least some of you that we are very close to defining the ideal intersection between the talents of the programmer, the data/document designer, and the style expert with XML, CSS and the DOM. XML puts control of the design process solidly back in the hands of the subject matter expert who designs the document types. CSS allows the designer to isolate the style issues cleanly . The DOM provides the programmer with an orderly approach to interactive application programming (including transformation) and prevents the the web document from becoming an incomprehensible mixture of code and data. XSL is a big step back, it mixes everything up again and puts everything in the hands of the few people who can understand this weird declaration thing which is simultaneously both past and future and in which nothing really ever "happens".
I mentioned the support in programming languages for managing complex tasks. I am talking about things that engineering scientists have studied and developed over many years of research into program design. Things like program modules, argument passing, scope, state, basic and complex data structures, naming conventions, debugging techniques. These are admittedly unfamiliar to people not trained to write programs and they may seem like an unnecessary complication. They are not: the proper use of such techniques will ensure that your transformations are readable and maintainable to people who can read and maintain programs and that the results will be reliable.
I'd like to offer another little challenge to those that are still unconvinced - go and read the XSL script used to produce Mr. Holman's article (http://www.xml.com/1999/04/holman/xmlcom.msxsl). Can you understand it? Is the fact that it is a declaration really making life any easier for me? He is doing basically really simple transformations, just gathering some element data to stick in tables at the end of the document - I gave the same assignment to a junior programmer on my team for him to learn the DOM. But it is enough to push XSL to the wall.