[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
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|