cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject XSL condidered harmful... by those who don't get it.
Date Fri, 03 Mar 2000 15:37:26 GMT
After reading Mr. Michael Leventhal
( papers I was shocked to see
how dangerous his reasonings are.

I will quote the most interesting things... hopefully trying not to
remove the sense by decontextualization. You should read the originals

"we at CITEC are building the following Web browser-based semantically 
rich XML applications: 


His equation is: one DTD one browser. Flexible, isn't it?

It gets even better:

"[a speaker doing XSL presentation] ... 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"."

What is he talking about? HTML is static as well. Scripting is what it
makes it dynamic. If you add scripting to FO it gets as dynamic as HTML
and has better typesetting capabilities built in from the beginning.

"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
on the Web is for, to enable such applications to be built using
information from element names, attributes and the document structure? 
This is what we thought and this is what we have been doing. We think
'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

I feel sorry for him. Once the XML infrastructure will be in place,
he'll be left with zillions of 'zillas and we'll have the original
mozilla that does everything for us in one place, helped with both
server side and client side XSL transformations.

Hey, man, if you like HTML + CSS + DOM + Javascript + what-do-I-know,
simply transform your XML sources into that. Sheesh.

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

Rant aside, this guys clearly missed the transformation capabilities of
XSL and focues on the complexity and "staticity" of FO. Missing it
twice: first missing the transformation part which is clearly much more
powerful that CSS, second FO is just what is is, a language for
describing 2D areas and text. Combined with SVG, SMIL, scripting and DOM
will beat the crap out of DHTML + CSS each and every day.

"A more important point is that XSL, as a web page style language, is an
 enormous unknown in terms of processing efficiency"

(he is clearly talking about FO at this point)

Have you guys used FOP standalone? Well, I have. It's written in Java
and it's as fast as HotJava... build this native and we're set. He
believes that HTML + CSS is faster to draw. Why? It might be true but
where are the technical details? He's just ranting all over the place.

"May I be so bold as to ask how much real world experience with CSS2 
the working group designing XSL has? Is this not a reasonable
for designing a new language which better addresses the needs of web 

I partially agree with this: FO is utterly complex and overlaps a great
deal with CSS. But FO is much more abstracted than CSS and could be
transformed into HTML + CSS algorithmically... the opposite is unlikely
to be true.

Unlike CSS that was invented to add better graphic capabilities to web
browsers, FO was designed as a typesettings language. I personally hate
the XSL acronym.. it's misleading. I would love to have 
 - XTL -> eXtenxible Transformation Language
 - FOL -> Formatting Object Language

this is how we should look at the picture. In this sense, he's right
saying that XSL is crap. There is nothing about stylesheets in XSL. It's
all about transformations, which might be more complex, this is true,
but definately more flexible and useful in tomorrow's web.

"The fact that interests us here however is that there already exists a 
way to do tree transformation that adheres to a W3C Recommendation
It is called the Document Object Model (DOM) and can be used in browsers 
now through its binding to JavaScript and other languages (Java, C++,

He cannot be serious about this. I hope he has changed his mind
somewhat: DOM + Java easier than XSLT? get real, dude!

"When compared to the DOM+CSS, XSL does not solve any Web-related
that the current W3C Recommendations do not adequately handle. What is
Big Deal indeed?" 

Need I say more ;-)

"I can understand why overworked undergraduates think FONT is cool, but 
I'm very disappointed when a group of highly skilled adults tell kids to
stop playing, form a committee - and then come out  with a set of 
supercharged FONT tags."

AHHHHHHHHGGGG!!!! He read the first line of the spec "eXtensible
Stylesheet Language" and stopped there. He's totally right if you think
about XSL as a stylesheet language. But it's not. FO is a final
language, one that should be directly rendered, not directly edited.

Is it that hard to understand?

"If the rendering engine reads formatting objects directly, all the 
semantic information in the original information may be lost."

Of course! It's not a semantic language, it's a 2d layout driving
language. But your browser will never reads those directly: it will read
an XML page with all the semantic information you need, then apply the
transformation and render that one.

But I do see part of his points...

"One must ask why don't we just forget about formatting objects and just 
use CSS in the first place?"

I say: why not? It's up to you. But nothing stops me from spitting XML +
CSS to a browser that understands it... but XSLT adds the power of
transforming one into another depending on client capacities.

"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". 

XSLT is harder than DOM + language? I don't believe so. Moreover, doing
an XSTL clone of wrap-up CSS behavior is a piece of cake to do. Even CSS
is declarative, even if uses that strange VRML-like syntax. CSS was
clearly invented for HTML and moved over for XML. XSLT learned from the
DSSSL mistakes and came out both useful and useable.

But it's a new paradigm and one must learn it to use it.

But again, nothing is imposing you to use XSL _or_ CSS, you can safely
use both of them on where you like it the best.

I never wanted to eliminate CSS.. we can even picture an XCSS language
that writes CSS in XML and use Cocoon to serialize it in their strange
syntax. Whatever.

There is only one good point: adding dynamic capabilities to FO looses
structure information and there is no defined way to add dynamism to an
XML page besides CSS.

The point can be outlined as: FO and CSS overlap, neither one covers the

But you know what? As long as I'm able to transform my XML into
something else, I'm fine and able to choose what I want.

But XSL has a nice place in the web world. Luckily, W3C directors have a
better vision than some of these guys.

Sorry for the harsh parts... I know these are old documents made before
XSLT was separated from XSL... but still, some of those arguments hold

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message