CSS + behavior vs. XSL (was: EcmaScript, gone?)

Paul Prescod wrote:

> I agree that the system must be made extensible somehow. I was never
> comfortable with the sprinkling of Javascript syntax, and the new XSL
> makes me think that we may be able to get away without it. As you probably
> know, there is a stylesheet-related concept called a "behaviour sheet."
> What if we allow "behaviour sheets" to modify the XML tree before it is
> displayed. Then the Javascript code would be nicely segmented and executed
> completely separately. XSL would remain completely declarative (like
> pre-Javascript HTML), but the fundamental flexiblity would be available
> (like post-DOM web pages).

I thought the original impetus behind XSL was to take it "beyond CSS" by adding
scripting. So if XSL is to be declarative, why not utilize the *much* more
straight-forward and declarative Cascading Style Sheets, and use -- as you
suggest -- "behavior sheets" for processing?

Or is there such an overwhelming urge in the current all-is-XML fever to
reinvent CSS (not to mention COBOL, C++, Postscript, Java, ...) in XML that we
have to thrash about for who knows how long in designing a new (essentially) CSS
syntax?  CSS is not only a full Recommendation, it's now a *Level 2* full
Recommendation!  XSL 1.0 will be ready when?  June/July '99 at the earliest?

Just what is it that XSL will do that CSS + behavior (or CSS + DOM) can't, other
than say "Hey, I'm way k3wl because I'm expressible in XML and similar to
Xpointer!"?

Something to think about anyway.


/Jelks


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list