Re: On loss of integrity with xsl:script...

> I'm also *not* trying to reopen a Jihad on the inclusion of script tags in
> XSL,

Are you sure? :->

> We seem to be facing a creep away from a descriptive language in
> order to cater for increased functionality, which although often marginal

Side effect free, functional or declarative languages don't need to be
short of functionality. Just need to look at examples such as lisp
(the pure part of it) Standard ML, Prolog even, or closser to home, dsssl.

> however, we had a script tag, that we could escape to for those marginal
> but essential tasks, might we not have exactly that, an escape

If you had some element rules that might possibly be changing the
global state then the whole character of the language is different.
You would always have to fully render the entire document before you
could render anything in case some rule changed some variable that
affects the rendering of the current node.

There is a major difference between allowing an extension mechanism that
essentially allows more functions to be added to the underlying engine,
but still in the same style as the functions already in the core, namely
acting on the parsed document tree, not the concrete syntax in the input
file, and side effect free, and adding a hook that allows imperative
programming constructs that cut right across the language.

David


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