Re: XSLT 1.1 comments

> FWIW, practically every case I see a user using XSLT with *:script, it is
> because what they really wanted was a way to do XPath from their favorite
> language, and they thought XSLT was the only way to programatically
> manipulate node-sets accessed via XPath.

I do agree with Joshua's sentiment.

The essence of what is billed as XSLT 1.1 could pretty much be your favorite 
programming language plus DOM and an XPath library.  If all the Java users 
want a Java unification for tree transforms, why don't they just do so in 
Java?  Why hack at XSLT?

I know that I often just go straight to 4XPath when it makes sense, and use 
XSLT when it makes sense.  I think it's a bad idea to try to make XSLT all 
things to all people, which I wouldn't have particularly thought of as a 
motivation for xsl:script until Scott Boag's implication in that direction.

"They are really meant to be a stop-gap measure until the language fullfills 
99% of what people need to do... which may be a while yet."

Pretty scary thought.

I also think a lot of extension-mongering would be minimized if there were a 
run-time evaluate function (the famous saxon:evaluate).  I do understand soem 
of the WG's original opposition to this, but I think a lot of things in XSLT 
1.0 and even more in 1.1 undermine this opposition.

I also like the idea expressed here of implementing extension functions in 
XSLT.


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