RE: [xsl] The evaluate function

Subject: RE: [xsl] The evaluate function
From: "Evan Lenz" <elenz@xxxxxxxxxxx>
Date: Wed, 2 Jan 2002 15:16:49 -0800
Mark Feblowitz wrote:
> What I don't understand is why there is an issue regarding static
> optimization. It would seem that those expressions that were to be
> dynamically evaluated could be flagged as such (e.g., using an explicit
> evaluate function) and not adversely affect optimized processing of static
> expressions. What am I missing?

Taking this argument reductio ad absurdum, it's also true that if someone
never uses the descendant axis (always specifying the absolute path
instead), then their stylesheets will be much easier to optimize. My point
is that if a language provides a feature, then not only does it have to be
implemented, but implementors have to expect that users will use it
(including cases where it's not even necessary or appropriate). What makes
certain language properties truly valuable is that they are unconditional.
An implementor of XSLT 1.0 is much aided by the knowledge that all
expressions will be known statically, that all imports will be known
statically, that all template priorities will be known statically, etc.

> Both Saxon and Xalan support evaluate functions. Are there widely used XSL
> processors that do not provide such a capability?

Without answering your question, I'll address what I think you're implying
:) If all XSLT processors have evaluate() anyway, why not make it standard?
My answer to that is that XSLT is a young language and implementations
relatively unsophisticated. The static properties of XSLT have been
relatively unleveraged. Moreover, traditional XSLT processors address only
one processing model, where input is accessed on-the-fly. There is work
being done, including at my company, on other processing models (e.g. XSLT
as a query language over a persistent database).

Introducing evaluate() now, IMHO, would be an example of premature


 XSL-List info and archive:

Current Thread