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

[Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>]

Catching up after a hectic week...

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

Interesting.  I must confess that I implement more run-time opt than 
compile-time (look-ahead trimming of node-sets, dynamic expression reordering, 
etc), and so this hadn't occurred to me.  Since compile-time optimization has 
much more potential, yours is a powerful argument.

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

Interesting.  Much like my argument againt scripting and bindings: the siren 
song might be irie, but the rocks are devastating.

I had once argued for xsl:evaluate in XSLT 1.1 rather than xsl:script, but I 
think it's worth waiting to see how implementers and users address your valid 
performance concerns.


> 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

Random brainstorn: would a cannonical XML comparator for nodes be useful as 
well?

> 2. No support for dates

Absolutely!  This is a well-standardized field, and there's no reason people 
have to ditch to external languages for such a fundamental facility.

> 3. No simple mechanism for grouping

Naaah!  I've never heard anyone ask 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.

Hear, hear!


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