Re: EcmaScript, gone?

Paul Prescod wrote on 28/08/98 00:51:

>As you probably
>know, there is a stylesheet-related concept called a "behaviour sheet."

I don't know about "behaviour sheet", but the idea seems quite 
interesting and does neatly separate declaration and code. True many HTML 
pages with JavaScript are a mess to read. Could you provide a sample?

>What if we allow "behaviour sheets" to modify the XML tree before it is
>displayed. 

The behaviour sheet is a separate file from the XSL stylesheet or else? 

>Then the Javascript code would be nicely segmented and executed
>completely separately. [...]
>This is an extra step, but it will have benefits that will become
>evident over time: more robust editors, more reliable transformations,
>stylesheets that work even when your Javascript has a bug, etc.

Agreed.

>Netscape has had a server side JavaScript implementation for a long time.
>ECMAScript seems at least as appropriate a language for server side
>manipulations as Perl.

I won't go into ECMAScript vs Perl (I'm sure others would like to see 
Java, Python, etc. and most importantly take advantage of their 
respective libraries), but we should absolutely leave the choice to the 
writer, not to the commitee. Commitee should standardize behaviour sheets 
calls within XSL but not impose how the sheets are written and processed. 
Imposing ECMAScript will definitively reduce XSL adoption rate. 

Of course, XSL processed on client-side by browsers will probably expect 
behaviour sheets to be written in ECMAScript, but a lot of XSL parsing 
will always happen on server-side IMHO.  



Francois Belanger
Sitepak, Bringing Internet Business into Focus
http://www.sitepak.com



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