Subject: RE: The top 10 limitations of XSLT 1.0 (was RE: [xsl] RE: Designs for XSLT functions) From: "Michael Kay" <mhkay@xxxxxxxxxxxx> Date: Wed, 21 Feb 2001 09:34:29 -0000 |
> 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: The top 10 limitations of XSLT , Clark C. Evans | Thread | Re: The top 10 limitations of XSLT , Jeni Tennison |
Re: Designs for XSLT functions (Was, Jeni Tennison | Date | Re: The top 10 limitations of XSLT , Michael Beddow |
Month |