Re: [xsl] XSLT 1.1 comments (in defence of xsl:script)

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

> I'd quite like to fill my stylesheets with XSLT ... thus my current
> campaign to get XSLT included as an xsl:script source language, or to
> add the equivalent of Mike Kay's saxon:function.  

So would I. I don't think that it would surprise anyone on this list if
I said I had no fondness for writing any procedural code at all.

> Between eg Saxon and MSXML3? 
yes. You can have as many xsl:script elements as you like, they don't
affect portability because they don't do anything.

> Not unless you code, test, document and
> optimise your extensions in both java and Jscript, surely?

there's the rub. If you are using extensions then your document isn't
portable. But at least with xsl:script it can be _made_ portable.
You can have one xsl:script binding the extension namespace to
some vbscript and another xsl:script binding it to a method in your java
classpath. With xslt 1.0 typically you have an extension namespace which
directly hooks into the fully qualified java name and any hope of
porting off java is small.  (One needs to distinguish between built in
extensions like saxon:evaluate and xt:node-set etc and which is a
separate issue, and the facility all XSLT 1.0 java enjines have of
binding essentially arbitrary java methods to extension functions.

> Surely the point is that xsl:script will encourage the development of a
> fragemented codebase that uses language-specific extensions. And
> inter-platform portability will suffer as a result. 

I don't buy that point at all.  All java XSLT 1.0 engines allow binding
of arbitrary java code to extension function names, but do it slightly
differently in each case. MSXSL has an extension element msxsl:script
that for the purposes of the discussion acts just like xsl:script.
Currently there's no sane way of making a stylesheet work on more than
one of these systems if it uses any extension at all. xsl:script
offers some hope of doing that.

> As long as there is no option to code extension functions in
> platform-portable XSLT, that goal will move further out of reach.

I fully support the idea of writing extension functions in xslt.

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