This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Lookup (?)
- From: David Carlisle <davidc at nag dot co dot uk>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Mon, 18 Feb 2002 22:03:40 GMT
- Subject: Re: [xsl] Lookup (?)
- References: <000701c1b8c2$32c74190$78fe0250@pcukmka>
- Reply-to: xsl-list at lists dot mulberrytech dot com
Mike
> 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.
But it's very hard for a library like EXSLT to wrap up different
evaluate functions from different namespaces to offer a consistent
interface to the user if the underlying implementations differ on the
edge cases like variable refs that you mentioned. So having a standard,
but optional, specification as part of the standard would be a big win.
Also of course the above issues with compilation are all good reasons
why it is better to add general functionality through higher order
functions which can be compiled rather than through evaluation
of strings as expressions.
However it seems that functions as objects has also moved to the back
burner for XSLT 2?
David
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list