Re: [xsl] xsl:script and side-effects

[David Carlisle <davidc at nag dot co dot uk>]

> With XSLT 1.1 + Java bindings though, users can introduce their
> *own* side-effecting operations, 

They can do that now, with XSL 1.0. _ALL_ the java based XSL engines
allow you to use a namespace (a different one for each processor)
that ends in the fully qualified java class name and thus lets you run
arbitrary methods from your class path.

It is the fact that you can not do this in a portable way because every 
processor binds differently that xsl:script is trying to solve.

> So we can end up with strictly conforming stylesheets that behave
> differently -- perhaps radically differently! -

But not because they have used xsl:script, because they have used an
extension function.

Put it another way, if you write a single XSL 1.1 stylesheet using
xsl:script to bind to a java method then I can give you a saxon
XSL 1.0 stylesheet that does the same thing, and an xt one and an xalan
one. The only difference is that for XSL 1.1 you have one stylesheet but
for XSL 1.0 you have three. This seems to be an improvement in
portability to me.

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.star.net.uk/stats.asp

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