This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: The top 10 limitations of XSLT 1.0 (was RE: RE: Designs for XSLT functions)
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: RE: The top 10 limitations of XSLT 1.0 (was RE: [xsl] RE: Designs for XSLT functions)
- From: "Michael Kay" <mhkay at iclway dot co dot uk>
- Date: Wed, 21 Feb 2001 09:34:29 -0000
- Reply-To: xsl-list at lists dot mulberrytech dot com
> 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