Having had an eval(...) in our implementation for many years, it is actually something I am working toward eliminating.

The problem with eval() is it opens you up to a raft of potential problems, such as XQuery injection attacks etc. Perhaps that is more of an implementation concern, but I just wanted to warn that eval() comes with downsides. We have found that we have been able to eliminate a lot of our use-cases for eval with higher-order-functions and fn:function-lookup. We think that with a dynamic module import facility we could eliminate even more of our use-cases for eval.

I am submitting this on behalf of Carole Mahoney:

Dear Members of the W3C XPath, XQuery, and XSLT Working Groups,

I am a department head overseeing software engineering staff who support multiple U.S. Federal government projects. Many of the projects we support  would benefit enormously from the ability to dynamically evaluate strings as XPath. I would like to request that a new XPath function be added. Here are several use cases followed by a description of the desired XPath function:

In one project there is an application that evaluates a series of XML documents; each document is evaluated based on a security policy. The policies are expressed as XPath, in a separate XML file. The application identifies suspicious nodes in the XML documents, bookmarks them using the XPath 3.0 path() function [1], and then generates a report showing the XPath to the suspicious nodes along with a description of the policy that has been violated. Then a security expert conducts a Reliable Human Review (RHR) of the report. Periodically the policies are modified. This currently involves stopping the application, reconfiguring the code, reaccrediting the code, and then reinstalling the application. This is extremely expensive and time-consuming. With a function that evaluates arbitrary XPath expressions our policy file could be updated and the application could dynamically evaluate the new policies. Thus, there would be no need to stop the application, reaccredit, and reinstall; this would result in a huge decrease in cost and a huge gain in efficiency. 

In another project we have operational rules, such as aircraft fuel consumption calculations and aircraft flight performance characteristics, expressed in XPath. These rules can be made more easily configurable if they are held in a separate file maintained by an operational expert. With a function that evaluates arbitrary XPath expressions, we will be able to have an application that reads in the operational rules and dynamically evaluates them.

Several projects have this situation: a user enters an XPath string that described how he wants data sorted or grouped. That is, the sort key and the grouping key are specified as external XPath expressions. An application then reads in the XPath string and dynamically evaluates them to sort/group the data.

Some projects want to use XPointer-like schemes for cross-referencing within or across documents using XPath expressions.

Our test teams would like to create test frameworks which use XPath expressions to make test assertions.

As you can see, we have important use cases in numerous projects that would benefit from the ability to dynamically evaluate strings as XPath expressions.

We are aware that a detailed specification of such a function will require definition of the static and dynamic context for the XPath evaluation. However, we think that the need for this is reduced by the new EQNames which make it possible to write XPath expressions with no dependency on the namespace context.

We are aware that some of the traditional use cases for dynamic evaluation are (better) handled using higher order functions; however, HOFs do not tackle all requirements.

We want this new functionality to be XPath that is evaluated because this new function will be used in our XQuery code, as well as our XSLT, Schematron, and XML Schema 1.1 code.

We humbly request that Working Groups provide a new function that takes one argument which is an arbitrary XPath expression, represented as a string, and returns the corresponding items. Perhaps it could be called: xpath-eval(), or some such thing. 

We imagine the new function behaving like this:

                xpath-eval('arbitrary xpath expression')

evaluate the string (which could be a map, a path expression, a function, etc.) and returns a sequence of items.

Thank you for your consideration.


Carole

Carole Mahoney
Department Head
E54C – Agile and Adaptive Software Engineering
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
781-271-8737
cmahoney@mitre.org

[1] The path() function is described here: http://www.w3.org/TR/xpath-functions-30/#func-path

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.

The Working Groups decided, at their joint teleconference on 2014-04-01, that this proposed feature is beyond the scope of the 3.1 suite of specifications. Therefore, this feature will not be included in version 3.1. However, we recognize the value and requirements for the feature, so we agree that it will be reconsidered for a future version of XPath, should one be developed.