[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: "Michael Kay" <mhkay@xxxxxxxxxxxx>
Date: Wed, 21 Feb 2001 09:34:29 -0000
xslt sort top 10
> 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.
>

(b) is true anyway: you need to know about namespaces at run-time if you use
key() or system-property() or function-available(). They are quite handy for
run-time diagnostics too! Just add evaluate() to the list of things that
prevent you discarding this information.

(c) is true anyway: format-number() always supplies the name of the required
decimal-format as a string. I suppose it's true that a compiler could
discard the decimal-format names if it recognizes that there is no call on
format-number that uses a non-constant third argument; but again, you just
have to add evaluate() to the list of conditions.

(a) is a new requirement. In my first implementation of evaluate() I didn't
allow variables, and they aren't strictly required, because you can
substitute their values into the expression string instead, using concat().
I allow them because I was keeping variable names around at run-time anyway,
e.g. for diagnostics. In defining a W3C spec for evaluate(), I would expect
that to be a matter for debate. One option would be an SQL-like solution:

evaluate("item[@code = '$1' and @desc = '$2']", $code, $desc)

I do think evaluate() is a very necessary extension to the spec, even though
I know it would probably be abused, because:

- people want to construct queries and sort keys dynamically from runtime
parameters supplied e.g. in a URL
- people want to use XPath expressions in their source document to represent
relationships

Mike Kay


 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.