> > 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.

This is no more true than in XSLT 1.0.

> 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.

And you can do the same thing with externally-implemented extensions in XSLT 
1.0.

> 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.

It is only as small as the Java implementor's (and indeed any language's 
implementor's) willingness to collaborate.

> (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.

Make this disctinction if you like, but all these issues can be dealt with 
just as effectively outside the core XSLT spec.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



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