This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT 1.1 comments
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] XSLT 1.1 comments
- From: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Date: Mon, 12 Feb 2001 23:28:58 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> 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@fourthought.com +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