XSL Does Not Support Interactive Web Documents

May 20, 1999

Michael Leventhal

With HTML forms included through the HTML namespace, but without CGI, and definitely without XSL, we at CITEC are building the following Web browser-based semantically rich XML applications:

DocZilla

Online Books/Manuals with Hypertext TOCs and structured search

CarZilla

Web browser designed for a car with simulated feeds to diagnostic and maintenance systems

LinkManagerZilla

Manages hyperlinks in document collections, providing interface, maintenance, editing and visualization of a link database and links targets and sources in documents

StockZilla

Simulated stock reporting feed, shown in this article

EmailZilla

Interface to email system

IETMZilla

Interactive Electronic Technical Manual Interface with special safety features

AnnotationZilla

Allows insertion of annotations into documents

HelpZilla

WindowsHelp-like system

SlideZilla

Does slide shows

EditorZilla

DTD-driven XML editor

I showed some of these applications at the XML Europe conference and also delivered my now-standard denunciation of the "XSL conspiracy". The speaker who had the misfortune to follow me was a very knowledgeable gentleman whom I respect very much, Neil Bradley (author of The Concise SGML Companion and The XML Companion), and the topic he had the misfortune to cover was, of course, XSL. And he began by saying that, of course, he would never attempt to create the applications he had just seen with XSL because "XSL is not for interactive documents".

Is there really anything more to say? If XSL is no good for interactive documents what do I need XSL for? Is there anyone out there that is not interested in enabling interactive behavior in a clean, structured, standard, and maintainable way in their web documents? Isn't that what XML on the Web is for, to enable such applications to be built using semantic information from element names, attributes and the document structure? This is what we thought and this is what we have been doing. We think our 'Zillas are the proof that XML on the Web does everything XML on the Web was promised to do. And we do it with XML, CSS, and the DOM and really cannot understand why anyone could, would or should give a damn about XSL.

The whole XSL process, described admirably enough in Mr. Holman's paper, is a static process. Interactive processes are designed around events which have event handlers associated with them. An event could, in principle, occur on any XML element (in fact we have done exactly this in many of our 'Zilla applications) and can invoke a myriad of behaviors which most often involve the modification of some element styling or perhaps the update of a element value. Occasionally, a little reordering of some part of one or more document trees takes place. Much less commonly, all or a large portion of the document is reordered, as in an application which updates a sorted table. The CSS model of attaching formatting to the elements is perfectly adapted to handling events which cause stylistic changes, and the DOM model is very efficient for updates to the document tree contents and local reordering. It is adequate for global reordering. In addition, the document trees often reside in different frames or windows and one must have communication between them. JavaScript provides these kinds of facilities as it is an environment native to the browser environment. When an event occurs you typically want to know what element it occurred on, what its name and attributes are, and most often you will be doing things that will effect its immediate children or parent. This is all elementary stuff if you're using the DOM and JavaScript. Finally, it all has to be very fast.

The XSL folks seem to be about a million miles from this, proposing a horse-and-buggy model in laser-guided precision missile world.