evaluate() is easy for an interpreter, but less easy for a compiler, because
the XPath expression isn't known until run-time, which means that not only
the XPath parser but also the context (symbol tables, functions, in-scope
namespaces, base URI) all need to be available at run-time.

I'm only passing on the objections made by other implementors, however: I'm
not saying I agree with the decision.

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx

> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of
> Carsten Klein
> Sent: 18 February 2002 20:36
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re:  Lookup (?)
>
>
> Thank Kay for the information, but
>
> > obliged to provide it, since it can greatly increase the
> difficulty (and
>                                                     ^^^^^^
>
> huh? The parser needs to evaluate the string value of the
> select statement
> anyhow
> therefore, the xf:evaluate() wouldn't be that much of overhead to the
> compiler, I presume.
> The current variables in scope and their values are known to
> the compiler at
> the time it
> stumbles accross the evaluate() statement, what's the problem?
>
> Hm, by now I decided to re-write my code to do this in
> javascript, selecting
> and deselecting
> parent and child nodes, therefore there is no need to do it
> xsl anymore.
>
> bye
>
> Carsten Klein
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


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