[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Lookup (?)
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|