This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Lookup (?)
- From: "Michael Kay" <michael dot h dot kay at ntlworld dot com>
- To: <xsl-list at lists dot mulberrytech dot com>
- Date: Mon, 18 Feb 2002 21:21:07 -0000
- Subject: RE: [xsl] Lookup (?)
- Reply-to: xsl-list at lists dot mulberrytech dot com
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@ntlworld.com
work: Michael.Kay@softwareag.com
> -----Original Message-----
> From: owner-xsl-list@lists.mulberrytech.com
> [mailto:owner-xsl-list@lists.mulberrytech.com]On Behalf Of
> Carsten Klein
> Sent: 18 February 2002 20:36
> To: xsl-list@lists.mulberrytech.com
> Subject: Re: [xsl] 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