...simple - just don't use script in XSLT unless you really really
really have to. Especially on the server side - XSLT script and ASP.NET
should never meet. Use XSLT extension objects instead. As simple as it is.
—Oleg Tkachenko—"XSLT scripting (msxsl:script) in .NET - pure
Amen, f'real. When XSLT 1.1 first emerged the first thing that jumped
out from the spec and punched me in the face was the embedded script
facility. I made a fuss about
In general, I think the re-introduction of xml:script is execrable.
XSLT 1.0 had perhaps the most elegant extension model possible, and
xsl:script ruins this by destroying the opacity of extensions to XSLT
processors. Language bindings may make sense in the realm of CORBA or
DOM, where the actual expression of the program is done in the bound
language, but XSLT is XSLT, and introducing the need for language
bindings only reduces general interoperability while giving a small
boost to interoperability between small axes of implementations.
I even worked with some like-minded folk to put together a
petition. I have
no idea whether that was instrumental in any way, but soon enough XSL
1.1 was dead and replaced with XSLT 2.0, which was built on XPath 2.0
and thus had other big
problems, but at least no
xsl:script does live on in some implementations, and notably MSXML, as
you can see from Oleg's post. You can also see some of the problems.
XSLT and many more general-purpose languages make for uncomfortable fit
and it can be hard for platform developers and users make things work
smoothly and reliably. More important than memory leaks, script-in-xsl
is a huge leak of XSLT's neat abstraction, and I think this makes XSLT
much less effective. For one thing users are tempted to take XSLT to
places where it does not fit. XSLT is not a general-purpose language.
At the same time users tend not to learn good XSLT design and techniques
because they scripting becomes an escape hatch. So an script user in
XSLT generally cripples the language at the same time he is over-using
it. An unfortunate combination indeed.
Oleg advocates XSLT extensions rather than scripting, which is correct,
but I do want to mention that once you get used to writing extensions,
it can be easy to slip into habits as bad as scripting. I've never been tempted to implement a Python scripting extension in 4XSLT, which would be easy, but that didn't stop me from going through a phase of overusing
think I've fully recovered, and the usage pattern I definitely recommend
is to write the general-purpose code in a general-purpose language
(Python, C#, whatever) and then call XSLT for the special and narrow
purpose of transforming XML, usually for the last mile of presentation.
It seems obvious, and yet it's a lesson that seems to require constant