Haven't we heard these before?

"Anything you can do with SMIL, I can do with plugins and JavaScript or DHTML"

"Anything you can do in C++, I can do in C, or Assembly. I can write object oriented programs in assembly language.."

And so on.

Any Turing Complete language can do anything that any other language can. I'm sure that Javascript Style Sheets can do anything that CSS can.

The point is, end users don't want to have to constantly write transformation engines OVER AND OVER in Javascript using DOM.

Can you imagine writing the following query?

"for each section, whose title attribute is the same as it's chapter attribute, when processing the table of contents, do the following..."

This is quite trivial to do in XSL or DSSSL, and irritating to write via Javascript and DOM calls "getElementsByName...for each child, check see if it is a section table, ok, now compare attributes, ...."

Consider the absurdity of eliminating CSS selectors and doing EVERYTHING via the DOM.

First of all, code would be

1) tedious to write 2) repeated over and over again 3) require more bandwidth to download 4) slower 5) uneditable by WYSIWYG because they don't understand complicated Javascript/DOM expressions used to target a specific node.

This DocZilla thing is nothing more than a blatant attempt to get press, and someone grinding a technical axe who obviously hasn't thought about the implications.

JavaScriptDOMTedious,

DocZilla is just CITEC's version of Mozilla that supports SGML (and other document types not supported by Mozilla). It's relationship to the XSL vs. XML/CSS/DOM argument is nonexistent, except as a supplemental way of evaluating his claims.

Oh, come on... do you REALLY think DocZilla won't get publicity if its developers jump up and down and rant?

mozillaZineAdmin, It is standard practice to write articles and publish them to get PR for your product/company. Every editorial that decries a competing technology is a subtle PR move. If you've ever written an article for a technical magazine, you would know that even if your company isn't it that area, you get PR out of it.

Irregardless, the DocZilla connection is that DocZilla claims you can view/print SGML with just CSS/DOM which is true, but a bogus argument and he should know better. Maybe they are too lazy to write an XSL/DSSSL engine for their SGML browser?

1) You can't *EDIT* any heavy DOM/JavaScript laden documents like you can with a declarative language like CSS, or XSL, or DSSSL. No one is going to write a two-way WYSIWYG editor like DreamWeaver that can automatically parse complicated DOM manipulation expressions and figure out what is going on, because DOM/JavaScript isn't side-effect free.

2) Declaration languages lead to BETTER optimization, not worse optimization as the DocZilla guy claims.

For example: With XSL you can use the filter paradigm to transform a document on-the-fly without using up memory. With DOM trickery, you end up creating a new document in memory. Some transformed documents can turn a 10K XML or SGML file into a 100k document of flow objects.

Or, with XSL expressions, you can compile them to a finite-state-automaton like with Regular Expressions and can search a document tree *much much* more efficiently than JavaScript loops and DOM calls.

There are so many technical arguments against DocZilla's article, including the existence of style transformation languages that are widely used in the SGML community, that I question the motives behind it. It smells like FUD.

Microsoft tried to pull the same stunt with SMIL saying "anything you can do with SMIL to synchronize multimedia,you can do with JavaScript controling plugins" Reason? Because they didn't have an implementation ready and RealNetworks had a good one.

Microsoft knows the right solution is specialized declarative languages, thats why they proposed Behavior Style Sheets, and Vector Markup Language.

And what do you know, a few weeks later, Microsoft proposed HTML+TIME which competes with SMIL in some ways.

Finally, James Clark, Jon Bosak, Tim Bray, and everyone else who have had years of experience with SGML, DSSSL, and XML have chimed in and shot his argument down.

It is all too tempting to accomplish something new by relying on hacking together a solution from the past. I mean, why do we need MathML? I can already transform LaTeX documents into HTML with GIFs substituting for complicated math expressions. Or, there are several java applets out there which already parse and render MathML, so why does Mozilla need it built in?

It's precisely this attitude, of trying to accomplish something with a quick fix, that got Netscape into trouble in the first place. They should have rewritten their rendering engine 2 years ago just like MS did instead of trying to hack CSS into Netscape. That codebase was *beyond* ugly.

Hell, you can even see people on Mozilla's newsgroups trying to find ways to render MathML with CSS and Gecko which is a totally bogus idea.

Do the work to support the right technical solution. Pay now, or pay later when you have to rewrite it anyway.

I never bothered investigating XSL fully, mostly because no-one had implemented CSS properly yet and XSL promised to be an order of magnitude more complicated. As far as Michael Leventhal's vested interests go, I couldn't care less. (English -->American translation: `I could care less'), as long as all of what he says is true.

By the way, JavaScriptDOMTedious, I couldn't disagree more with your dismissal of MathML. My reasons are too long to include here, so I've submitted them to MozillaZine as a separate article.

-- mpt

The article is called `XSL considered harmful'. I know `considered harmful' is getting to be a cliche now, but can anyone tell me who first made it famous?

Ta

-- mpt

Gee mpt,

I couldn't disagree with you more.

However, my reasons are much too lengthy for me to state here.

Maybe I'll submit an article, eh?

Well what really is the real winnings with XSL anyway?

I am Michael Leventhal, author of the article in XML.com "XSL Considered Harmful".

I have a few points to make in response to comments here.

First, with respect to the attacks against my motives or the assertion that I "haven't thought about the implications" I don't think this sort of thing deserves a response. Read the article and judge it and judge me on the article's technical merits. I ask nothing more ... or less.

The fact that some commentators have not done this is clear as they appear unaware that I make five points against XSL, not just the ones attacked in isolation and out of context.

The major point about the challenge "whatever XSL can do current W3C Recommendations can do better" is that XSL, which is very far from being a W3C Recommendation and therefore able to implemented in a standard, cross-vendor fashion, will not add any new _capability_ above what can be accomplished with the current full Recommendations. So a future XSL W3C Recommendation will only provide a language more to some people's "taste". Obviously the first thing to do is to implement the W3C Recommendations, XML 1.0, DOM, CSS fully and correctly first as this is the foundation of the next generation of Web browsers. And this is exactly what Mozilla has done.

Now, as to whether or not XSL should be the language for transformation which is more to everyone's "taste" or not I must refer you to the article and my other points about the language where this is discussed in depth.

By the way, no one has "shot [my] argument down", Tim Bray, the co-father of XML is "80% in agreement with me", and very, very far from everyone else who have had years of experience with SGML disagrees with me. Quite the other way around. I am among those with many years of SGML experience myself.

God, the things people say!

if XSL can't do what dhtml (xml+css+dom) does then it's DOA. The fact remains that MS's focusing on xsl instead of complete w3c compliance sets us back. Granted there may be nice things about some parts of xsl but the web would be _much_ better if every browser could render the same content.

Michael,

Your article is available in two versions... XML and HTML. May I ask why that is? ...and how that was done? For me, the fact that both are available is the crux of the issue. We are a LONG way from XML+CSS on every desktop. XSLT, although it isn't yet a W3C recommendation, can be implemented today on the server, realtime or preprocessed, totally invisible to the end user. Personally, I think XSLT is the killer-app that allows XML to finagle it's way into the mainstream.

-head

Original use of the phrase "considered harmful" in the title of computing articles dates back to an item in the March 1968 edition of CACM by Edsger Dijkstra, "Go To Statement Considered Harmful".

http://www.acm.org/classics/oct95/

Now I think I understand XSL. It seems that XSL is the style equivalent of functional programming (e.g. Haskell), whereas CSS+DOM is the equivalent of procedural programming (e.g. C).

Now I've done a fair bit of functional programmin, and it can achieve some things very elegantly -- far more elegantly than procedural programming does. BUT which kind of programming is used most often in the real world? Procedural programming, by far, because it's (a) more useful, (b) easier to implement, and (c) quicker to execute.

I think the same applies to styling mechanisms. CSS+DOM is far more useful than XSL, so that's what browsers should concentrate on now. XSL can wait until CSS is fully implemented, for the specialist applications which really need it.

-- mpt

PS: Ian Young -- thanks for the link. Naboo -- I'm looking forward to your article. :-P

> Michael, > Your article is available in two versions... XML and HTML. May I ask why that is?

Because XML.com has the policy of publishing in HTML and offering the XML if the author creates it. I wrote the article in XML with a CSS stylesheet using DocZilla and Gecko to view it and then dumbed it down so it would work in IE5 too.

> ...and how that was done?

The HTML was created with search and replace in an emacs-like editor.

> For me, the fact that both are available is the crux of the issue. We are a LONG > way from XML+CSS on every desktop.

Damn straight! Thank God it's on my desktop though, thanks to Mozilla.

Do you think there is any particularly good reason why XML+CSS isn't on every desktop? Mozilla has certainly proven that it works and works REAL GOOD.

> XSLT, although it isn't yet a W3C recommendation, can be implemented today on the server, realtime > or preprocessed,

I don't care what you use on the server and I don't even see any need for it to be a W3C Recommendation. There are a ton of choices for doing transformations to HTML (since this is your point), many of us, myself included, have already been doing this for years and years and years - without XSLT. I am talking only about what goes into the client. XSLT on the client is irrelevant and XSL Formatting Objects are positively dangerous.

Michael

Just a reminder: if you always convert yor XML documents on the server to HTML, the user loses the benefits of smart markup. Sure, you can send a query to the server and let it search in XML and again return results in HTML, but one of the reasons why XML was created in the first place was to enable smart searches on the client (and thus reducing network traffic and load on the server).

It is true that we do not have too many options for browsers capable of handling XML. And I think Michael is right on target for blaming XSL for some of the delay.

The XSL standard is broken into two halves, the XSL transformation language and the XSL Formatting Objects. XSL-T has generated a lot of excitement with developers, whereas XSL-FO has generated a lot of excitement with marketing morons.

XSL-T is a good thing. It's a way of manipulating XML documents comparable to manipulating text with regular expressions. Combined with an extension mechanism into a scripting or regular language (such as Saxon, see http://home.iclweb.com/icl2/mhkay/saxon.html) it's a great way to rapidly develop XML-smart applications.

XSL-FO, on the other hand, is garbage. When I first saw XSL, Microsoft's minions stuck XSL-FO in my face so I wouldn't see the brilliance of XML-T. XSL-FO makes most people who see it feel sick -- instinctually, it's clear that the same minds who designed the "office packages" that let third-rate secretaries and local pizza chains torment me with fifth-rate documents wanted to infect the web with more documents that look like hell.

Why is XSL-FO garbage?

I honestly don't get it and what does Microsoft have to do with it?

XSL-FO is an attempt to print DSSSL style formatting into the XML world. XSL-FO is even being harmonized with CSS so that XSL-FO is nothing more than a superset of CSS. Think of it as CSS3.

There is still lots of formatting control that CSS *cannot do* that is vitally important for publishing. How do you support multicolumn output? Like Netscape's <multicol> tag? Tables don't work.

There is a lot of Fear, Uncertainty, and Doubt going on here.

Just because you looked at XSL-FO and didn't immediately understand it doesn't mean it's bad. I'm sure the first time someone encounters the zillons of propertiesin the CSS2 spec they are overwhelmed too.

Frankly, I think there is a lot of luddism going on here and little real criticism despite what the DocZilla guy claims. First of all, his whole "XSLFO will destroy the web" comment is a direct ripoff of Hakon-Lie's essay.

IMHO, CSS destroys HTML semantics just as easily as XSLFO because many HTML editors generate <SPAN class=x> for everything, with the class being the semantics. Is an HTML document composed of <FONT> tags and <SPAN> tags and nothing else, meaningful?

The second major criticism I have of DocZilla's comments is this:

Is a Web full of documents that are weighed down with JavaScript/DOM code a good thing?

I would argument that such documents are unmaintainable. Their presentational aspects are inaccessible except by script editors.

How is a style-sheet-editor supposed to show an end user how an XML document is being rendered if all of the selection code is DOM/JavaScript fragments?

Basically, if you argue against XSL/XSLT/XTL, you are arguing against the utility of SQL, Regular Expressions, CSS selectors, and every other pattern matching / action oriented declarative language.

If CSS selectors aren't powerful enough to handle XML document transformation (think RDF), and CSS flow objects aren't powerful enough for real publishing tasks like word processors (multicolumn output for example), then people are going to accomplish these things with PDF, ActiveX controls, or whatever else they need, and that to me is the real travesty.

If you don't like XSL, fine, let's argument specifics, or invent something else that does similar things, but if you're saying that CSS doesn't need to be improved or that JavaScript/DOM is enough, I think you are out of your mind.

I think that whether or not people think that XSL is superior to CSS, it is important that Mozilla add support for it solely for the reason that Microsoft supports it. It would be to Microsoft's advantage for Mozilla to neglect supporting something that they support because they can then claim that they support formats that Mozilla doesn't, and therefor pages written using those formats cannot be read by mozilla's browser. This seems to be how Microsoft corners every market. Furthermore, Mozilla should be capable af reading Microsoft's implementation of the pre-released version of XSL so that whatever has been written for that implementation (I only know of one article) can also be read for Mozilla.

Michael did not say that CSS does not need to be improved. CSS should be IMPLEMENTED properly before embarking on quests for the Holy Grail. As it stands now, the world has been chasing the Holy Grail and has forgotten that we could do everything the magical thing promises to do today with existing specs.

We still have no 100% CSS implementation in a *released* product. Of course we all know that that will change when the first browser utilizing Mozilla source ships...

In CSS one element in the source markup coresponds directly with one box on the screen. If you want text from one element to flow from one box to another (like "chained boxes" in some DTP programs) it seems to me you have to in some way decouple the box-properties from the markup elements. I think that is one capapility CSS does not have.

I dont know if this is a capability we actually need on the web, but if we want formating with PDF-like power, it is required.

> "XSLFO will destroy the web" comment is a direct ripoff of Hakon-Lie's essay.

It isn't a "ripoff" - it is nearly a direct quote. I state in my paper that Håkon Lie has written an irreproachable paper on the topic and ask the reader to look at it closely to get the complete story.

I don't see your point. Is there some reason I shouldn't encourage people to read Håkon Lie's paper if I think what he wrote is valuable?

Michael Leventhal

>I think that whether or not people think that XSL is superior to CSS, it is important that Mozilla add support for it solely for the reason that Microsoft supports it.

I think this is a very interesting point. I, of course, really want Mozilla to be successful in competing with IE so I am very sympathetic to your point of view.

However, it really is not sure that XSL will become a W3C Recommendation - obviously I am advocating against it and I certainly hope that at least nothing like the present XSL ever is. If XSL does not become a W3C Recommendation I think Microsoft does not get any advantage from what they've got now. Certainly not compared to Mozilla's superlative CSS and DOM support.

Secondly, as the article in XML.com in support of XSL by Ken Holman points out, Microsoft's implementation of XSL is already considered at great deviance from the XSL draft and perhaps even an abuse of it. If I were giving advice to one of consulting clients I would, unquestionably, have to tell them to steer clear of XSL in IE5. XSL in IE5 has been a big marketing lever for Microsoft but it is not a valid technology choice unless you only care if your pages work under IE5 and not in any browser to come in the future from Microsoft or anyone else. I believe Microsoft themselves describe their XSL implementation as being for the purposes of "experimentation".

Michael Leventhal

> I dont know if this is a capability we actually need on the web, but if we want formating with PDF-like power, it is required.

Well, for formatting with PDF-like power there is ... PDF.

There was something called SPDL (Standard Page Description Language) - an ISO standard. I wonder what happened with that? I think it was more or less supposed to be "standard" PDF.

I think we should also remember the special characteristics of the on-line environment. PDF certainly proves that paper-style formatting is possible but the amount of PDF on the Web is still around 1% despite the tight integration of the Acrobat viewer. There are alot of good technical and aesthetic reasons for this.

Michael Leventhal

> The XSL standard is broken into two halves, the XSL transformation language and the XSL Formatting Objects. XSL-T has generated a lot of excitement with developers, whereas XSL-FO has generated a lot of excitement with marketing morons.

As you know, I don't share your excitement about XSLT although I do understand the reason for it. On the other hand we agree about XSL-FO. A world in which we had XSLT and not XSL-FO is a world I would not find ideal but I could certainly live in it. I hope that people like you will raise your voices loud and clear for totally separating and removing an dependency between XSLT and XSL-FO so at least the latter can languish as it deserves.

Michael Leventhal

Michael, Please explain to me how I can achieve multicolumn output "newspaper" style using CSS/JavaScript only, that is independent of screen size and fonts?

The only way of currently achieving this is with Netscape's <MULTICOL> tag, which has no corresponding CSS model.

TABLEs don't cut it.

Right now, online magazines try to similate this with tables and chopping the article up by hand. It is not something web developers want, it is used by a *lot* of online webzines. Smaller columns are easier to read for people.

If I want to publish an article article in multicolumn format, ala LaTeX's multicolumn mode, or like I can in Word, or PDF, how do I do it?

In all of your responses, you still haven't answered the question as to how DOM manipulation will be editable by WYSIWYG editors.

CSS selectors aren't even powerful enough to generate a table of contents, index, or cross-reference. CSS also cannot handle XLINK.

So the question is, how will I edit my table of contents in an editor if it is nothing but a bunch of getElementsByTagName calls followed by script comparison statements?

There is a very real need on the web to generate multicolumn output, justified output, tables of contents, cross references, indexes, glossaries, sorted output.

Your assumption is that XML documents will be primarily tailored for display. That is, the flow of the structure will correspond mostly to the flow of blocks in CSS.

But this is clearly bogus when you look at CML, CDF, RDF, XMLEDI, OFX, OBI, OSD, and all the other XML formats that have been defined.

If all you have to display XML is CSS, you end up writing XML DTD's that are more like HTML with the tags renamed. Ho-Hum.

Actually, after a second look, I see that you have made some valid points that never crossed my mind.

Maybe I will reconsider my challenge.

Michael Leventhal

Well, I'll dispute the need for multicolumn output on the web. Personally, that's the last thing I think we need. Scrolling up and down a page repeatedly is not only tedious, it's unnecessary. I have *never* seen a page that would have been improved by multi-column content, and I've never seen a multi-column page that I thought required it.

And no I don't think pdf is the way to go. It has all the formatting but none of the interactivity. It's like using gifs instead of mathml. But XSL isn't so good in this field either. Before scrapping css+dom please make sure your replacement is just as good.

Well, it happens that for people who's native language is primarily oriented left-to-right and up-to-down, that having smaller columns is easier to read. Our words are primarily oriented horizontally and it is easier to read a sentence if your eyes don't have to travel very far left to write.

If you were right and multicolumn text isn't easier to read, then why does every print publishing house in existence use multicolumn output, OR, fonts or page sizes smaller, that you are effectively looking at a single column (ala paperback)

Consider the following reductio ad absurdum: Imagine an essay that is printed out on a wall chart so that sentences are 2 foot wide. Now imagine one where sentences are 2 inches wide, but the wall chart is 2 feet high. What's easier? Reading very long sentences left to right, or reading small sentences up/down?

Even if you don't personally think it is needed, the fact remains that *you* are not the audience. The audience is everyone else, the real world, that still uses multicolumn.

Furthermore, my argument doesn't just rest on multicolumn output. I personally, don't know much more amount XSL's flow objects. I am more interested in transforming documents. I was just using multicolumn as an example of why XSL's flow objects alone are something people should consider adding to CSS3, even if you don't like the transformation aspects.

CSS lacks transformation abilities. It can only display or not display something and change the way it looks. It cannot reorder the structure of a document.

It cannot even do something simple like generate a table of contents or glossary. To do that, you would need to write Javascript to scan the whole document and build them in a DOM tree, which is tedious like I said. It also means everyone reinvents the wheel for what should be a very common operation. (scaning and matching nodes)

Finally, the whole debate assumes that XML documents are being published in the structure that they will ultimately display in, with just CSS window dressing.

I beg to differ, and if that is the class, I fail to see the point of XML. I think XML's real value is not reinventing HTML, but in encoding human knowledge: buying decisions, ecommerce, supply chain, medical records, knowledge management, ontologies, mathematical expressions (MathML), CAD, gene sequences, etc etc

These types of documents won't work with CSS display at all.

Even RDF won't, and the fact that Mozilla needs a specialized Widget to handle it is a testament to the problem.

XSL would have no problem turning a flattened RDF graph into a tree for display.

IMHO, CSS display is low hanging fruit. CSS needs to work, it needs to be perfected and laid as a foundation. CSS flow objects need to be harmonized with XSLFO. But, CSS alone is not enough to do all the work of displaying XML, and using Javascript is just a hack to accomplish it.

I really sense something else at work here. I sense backstage politics. I sense that CSS is Hakon-Lie's baby, and XSL is not. In fact, XSL is more Microsoft territory and MS was first out of the gates with an implementation.

So is not some of this anti-XSL hysteria related to Microsoft?

Consider the statements: "XSL has set the web back 2 years" How can something which is not used BY ANYONE, and not supported by any browser that ordinary users have, set the web back?

Sheesh, it hasn't even been released yet and people are proclaiming the end of the world.

Maybe MozillaZine feels that Mozilla will be upstaged by MS in the developer mindshare by using XSL to do an end-run about CSS. For example, Mozilla will proclaim "Our browser has the only compliant CSS implementation..." and by that point, web developers will be saying "who cares, XSL is where it's out now. CSS is legacy. " Is that what is driving this fear and hysteria?

If anything, Gecko will have a head start on any XSL implementation, since they can map most of XSL's style objects directly to CSS blocks. Then all they'd have to do is figure a way to extend the engine to handle the additional ones.

I would hope that Mozilla ends up supporting more W3C/IETF standards than IE. Like P3P, XSL, OSD, SVG, MathML, WebDAV, SMIL, CSS2, etc.

I feel this is the better scenario, rather than crying "wah! please don't let MS create any more standards that we have to support"

If Open-source is so great, Mozilla should be able to support more than IE5 does.

I was speaking of multi-column text on websites, not in print.

JavascriptDOMIsTedious,

You really go out of your way to make absurd insinuations about people's reasoning. I really don't have feelings one way or another about XSL. If it becomes a standard, it should be supported - eventually. HTML 4.0, CSS1 and 2 *are* standards, and should be supported before XSL, IMO. However, your "multicolumn" argument was specious, and that's what I commented on.

I have no concern regarding MS's support of XSL.

The following message was a forgery. I am posting only with the "Name" option and anyone else may do the same with my name. I did not expect this kind of behavior on this type of forum so did not take the precaution of a password protected account.

JavascriptDOMIsTedious, may I ask if this was a little joke on your part?

Others may want to consider being more cautious on this forum.

Michael Leventhal

>Actually, after a second look, I see that you have made some valid points that never crossed my mind. >Maybe I will reconsider my challenge. >Michael Leventhal

Whoever it is claiming that my posts at Mozillazine are forgery, I suggest you email me personally to discuss whatever problem it is you have with me or the decisions that I make.

Michael Leventhal

Ack! OK, someone please enlighten me! Will the *REAL* Michael Leventhal, if he's really here at all, please stand up? I'm terribly confused.

I am the real Michael Leventhal.

I think! hehe! :)

Michael Leventhal

this isn't funny

>How can something which is not used BY ANYONE, and not supported by any browser that ordinary users have, set the web back?

Microsoft for one has invested a great deal in advocating and implementing XSL. Wouldn't you agree that if they had used all those resources to implement proper CSS and DOM we would have superior implementations of CSS and DOM in IE already?

And consider all those people converting their XML to HTML to get it to display in the crappy browsers we have now.

And still, consider all the web designers and their pain in designing web pages when they have to test their pages with every possible browser out there to see that it works in each and every one. And finally decide they cannot use CSS at all and must stick with plain old HTML without CSS. I am sure if you bought mozineAdmin a beer he would be telling you about the problems he's faced 'till the next millenium ;)

I should also add to the previous message that if Microsoft had implemented 100% CSS, Netscape would have been forced to do that as well. Might have affected other browser vendors as well, but since implementing 100% is hard they may already be doing the best they can.

It seems silly to say this - but I am the real Michael Leventhal logging on from a registered MozillaZine account. This account uses my business email address of mle@citec.fi and I also have a personal account at michael@textscience.com. Any postings not coming from this mozillaZine account are not coming from me. No messages from name "Michael Leventhal" since one identifying the forgery have been from me.

I am sorry mozillaZine readers had to subjected to this kind of conduct from the individual who perpetrated it.

Michael Leventhal

Such an elevated and useful discussion this has become.

You know, up until the forgery, I was enjoying it. And actually <shudder> learning something.

I guess some people can't stand that.

There's an ad hoc use of XSL engines which is extremely useful: both IBM's and Microsoft's (I haven't checked others) provide methods for querying an XML document using the pattern language in XSL. I'll call this usage "XQL" for short.

This seems extremely useful on both the client and the server. It can be very much faster than manual navigation, since it can be integrated with the DOM.

I'll miss not having XSL on Mozill for this capability alone.

The other issues of XSLT and XSLF have been discussed by other folks better than I can.

-AbnerD

Where can I find DOM+JavaScript example from 'XSL Considered Harmful' part 2?

Where can I find DOM+JavaScript example from 'XSL Considered Harmful' part 2?