[Bug 9065] [XQ31ReqUC] eval()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=9065

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike@saxonica.com

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
Adam Retter's point about the downsides of eval() is well taken; Saxon has had
such a function for many years, and it is sometimes abused. It's also true that
there are fewer valid use-cases than in the past because of the introduction of
higher-order functions, function-lookup(), and of course XSLT 3.0's
xsl:evaluate. Nevertheless, there are many applications where it makes sense to
use XPath expressions as data (for example, within source documents) and we
should be able to evaluate them; the fact that we can now generate paths using
fn:path() adds weight to this.

The main practical concern is how to establish the static and dynamic
evaluation context. The important parts (where users need control) are the
namespace bindings and variable bindings. Variable bindings can now be handled
very easily with a map: the keys are the variable names, the values are the
variable values, and the types are inferred from the values. Namespace bindings
are a bit trickier. The most usable solution is probably to supply an element
node; the namespace bindings for the expression are then the in-scope
namespaces of this element. The context item should be taken from the dynamic
context of the eval() call.

In xsl:evaluate, stylesheet functions are available for use within the dynamic
XPath expression. I think this should also be the case for an eval() function.
This does mean that such functions cannot be "optimized away" at compile time;
but we have already imposed this with the introduction of fn:function-lookup().

By contrast, stylesheet variables should definitely NOT be available; this
would constrain an optimizer too much.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 6 September 2013 09:50:35 UTC