Re: The evaluate function

Trevor Nash wrote:
>>The possible performance hit is, in my opinion, not enough of a
>>reason to omit a facility that makes the impossible possible.
>
> Nothing is impossible ;-)

As they say... but I challenge you to come up with a stylesheet that
parses and interprets any XPath expression. I've done templates for
the parsing side (only for XPath 1.0, of course), and that wasn't
easy. The evaluation side is even harder, and I would say that unless
you know what variables are available, using XSLT to evaluate XPath
expressions including variable references is impossible, in the
strictest sense of the term. As for creating XSLT to evaluate
extension functions, I think that involves writing an XSLT processor
in XSLT...

> I also care about reliability. If the compiler doesn't see half the
> source code, it will also miss half the errors. Some of which we'll
> see on this list ;-((
>
> I do worry that 'eval' could create more problems than it solves.  To
> quote another message today:
>
>> <xsl:value-of select="concat('/result/row[1]/column[', position(),']/@name')"/>
>
> Could be the next disable-output-escaping!

I think these are valid concerns. However, for all the complaints that
we make about people using disable-output-escaping, we rarely suggest
that it should be removed from the language just because people who
don't know any better use it inappropriately.

I guess that the reason that I'm arguing for evaluate() is because I
fear that it will be the next grouping. It is a feature for which
there is evident demand, even now, and I believe that there will be
more demand in the future as XSLT use becomes more sophisticated and
there are more markup languages around using XPath.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list