[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The top 10 limitations of XSLT 1.0 (was RE: RE: De

Subject: Re: The top 10 limitations of XSLT 1.0 (was RE: RE: Designs for XSLT functions)
From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>
Date: Wed, 28 Feb 2001 10:48:04 -0700
xsl evaluate
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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.