MozillaZine

The XSL Challenge

Friday May 21st, 1999

C. David Tallman has news of an interesting article at XML.com. In it, Michael Leventhal of CITEC (the group creating DocZilla) takes off the gloves and challenges XSL to best XML/CSS/DOM in a competition of functionality/usability in the web application space. Interestingly, Mozilla plays an important role in the contest. From XML.com:

"Anything XSL can do in the Web environment, I can do better using technologies supported by current W3C Recommendations. Of course, what is 'meaningful' in the Web environment is open to a variety of interpretations. Therefore, the subject of the challenge should be one that the XSL camp and I agree is meaningful. I am also ready to make this bet a little bit more than an academic exercise. If I lose, I will pledge that I, and my crack mozilla development team, will assist in implementing XSL in the mozilla open source project. If my opponents lose they will agree to desist from XSL advocacy, vote against an XSL Recommendation if they are members of the W3C, and will join me in calling for full, flawless, and unequivocal vendor support of CSS1 and CSS2, DOM Level 1, and XML 1.0 as the very first and top priority of the web community."


#17 Re:The XSL Challenge

by JavascriptDOMIsTedious

Monday May 24th, 1999 12:56 PM

You are replying to this message

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.