XSL Considered Harmful
by Michael Leventhal
|
Pages: 1, 2, 3, 4, 5, 6
XSL is an Ugly, Difficult Language
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.
|
XSL has Set Back the Web at least 2 Years
When I have criticized Microsoft for the lack of complete and correct CSS support in IE5, I have found that many are quick to class me among the irrational Microsoft bashers. In fact I am keenly interested in seeing Microsoft create a browser which adheres to Web standards. I want to see this because I believe that to a significant extent it is the character of our new information-based civilization which is at stake. I also happen to believe that we will sell many more of our 'Zillas if the technology we use is also supported by Microsoft and by other browser vendors. Finally, I think that the vendors can be persuaded that it is in their interest to support web standards if consistent pressure is applied to them from the marketplace and from those people who are the catalysts for new technological developments.
Today there is one and only one W3C Recommendation for the formatting of XML documents on the Web, CSS. Today there is one and only one W3C Recommendation for transformation and manipulation of XML documents, DOM. This year we could have had semantic markup on the web, in the major browsers, with support for XML 1.0, CSS and the DOM. This did not happen and I am sorry to say that XSL advocates that did not clearly articulate their support for current Web Recommendations contributed heavily to that state of affairs.
I think it is clear to all that the early implementation of XSL by Microsoft was a disaster. As predicted, the next version of the W3C XSL draft created two XSLs, the W3C's and Microsoft's. But more important than this is the fact that XSL has been a major marketing coup for Microsoft in enabling them to "hide" their deficient implementations of web Recommendations and to force the entire marketplace to postpone XML implementations for another couple of years while we wait for common standards that work in the all the major vendor's products.
|
The second part of this article consists of a comparison of the well-known Microsoft stock-sorting XSL and an enhanced application which uses the DOM and CSS instead of XSL.
