Re: XSLT 1.1 comments

> 
> 
>   Implementations can provide this functionality *independent*
>   of the language the XSLT processor is written in.
> 
> NO! They can't that is what I was trying to say.

Yes they can.  Language-independent interfaces have a long pedigree: see COM, 
CORBA, and many application CLIs.

> The above is a description of saxon:node-set and friends
> other implementations could choose to implement saxon's namespace full
> of built in extensions and that would work as you describe.
> 
> But that kind of extension functionality is unchanged in 1.1.
> 
> what xsl:script is trying to do is give similar flexibility to
> what currently in saxon or xt you would do
> 
> 
> <xsl:value-of
> xmlns:fudge="http://www.jclark.com/xt/java/the.full.java.name"
>   select="fudge:randomMethodInThisClass($x)"/>
> 
> That is, saxon, xalan, xt, and friends can execute arbitrary java
> methods that happen to be in your classpath. The namespace used for the
> extension function directly points at at the java class (although not
> directly at a particu;ar implemntation).
> 
> xsl:script gives an indirection allowing this to be more portable.
> Rather than use a namespace directing you to a java class, use a random
> namespace and then offere several possible bindings of that namespace to
> implementations, java vbscript or whatever.

And you're having no better luck than anyone else as to why this particular 
URI munging scheme deserves special status within the XSLT specification.


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