[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

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

---

---

> 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

---