The top 10 limitations of XSLT 1.0 (was RE: [xsl] RE: Designs for XSLT functions)

[Andrew Kimball <akimball@xxxxxxxxxxxxx>]

I have a couple of related reservations about an evaluate function:

1. Consider the following expression:
	evaluate('format-number(1.0, "##", $dyn-format-name)')

	This expression requires:
	a. A snapshot of in-scope variables must be retained so that
$dyn-format-name can be resolved at runtime.
	b. A snapshot of in-scope namespaces must be retained so that the
xsl:decimal-format QName can be resolved at runtime (core XSLT requires this
in some cases, but an evaluate function would always require it).
	c. All xsl:decimal-format symbols must be retained so that the Name
parameter can be looked up at runtime.

Essentially, sections of the symbol table which could previously be thrown
away after compilation must now be retained until runtime.  It also means
that unused variables cannot be optimized away, since they might be
referenced from within evaulate.  In general, a compile-time optimizer is
stopped cold when it encounters 'evaluate'.

2. Introduction of runtime evaluation to a language invariably leads users
down the broad path to miserable performance.  Its siren song promises
flexibility and simplicity, and indeed those advantages it often provides.
But underneath the beauty hides a fearsome hag.  Runtime evaluation becomes
universal duct tape for any limitation or inconvenience.  Rather than fixing
the language or using (less convenient) alternatives, evaluate becomes the
comfortable crutch.  Transformations which once sprinted now limp along.
And its all too easy...too tempting...

I realize that msxsl:script (or equivalent) has some of these same
disadvantages.  But I (like some others on the list), see msxsl:script as a
last resort.  Only uncommon and strange transformations should require the
escape mechanism.  If some common transformations require msxsl:script
(which is unfortunately the case at present), then XSLT needs to be amended
(which it is).

Some of the acute limitations of XSLT 1.0 I can think of off the top of my
head are:
1. The lack of real string comparison
2. No support for dates
3. No simple mechanism for grouping
4. No querying into RTF's

If the top 10 limitations of XSLT 1.0 were solved, then I think the roar of
demand for xsl:script and xsl:evaluate would be reduced to a whimper.

So, what are the top 10 limitations (functional, not syntatic) of XSLT 1.0?
That would be an interesting question to publicly discuss and perhaps put to
a vote to get a more objective idea of consensus.

~Andy Kimball


-----Original Message-----
From: Michael Kay [mailto:mhkay@xxxxxxxxxxxx]
Sent: Tuesday, February 20, 2001 1:35 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] RE: Designs for XSLT functions


> An XSLT compiler would
> have to include a complete XPATH interpreter in its runtime system!

Or use an implementation of DOM3, which will have one built in.

Mike Kay

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



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