[jdom-interest] suggested JDOM2 improvements

[Michael Kay]

 >The only case where we can't compile XPath expressions is when we want 
to use variables. Which defeats the whole purpose of compiling XPath!

Absolutely!

 >Or we have to use thread-local compiled XPaths. So, I think it would 
be great to split the XPath API in two parts.

That' definitely the way to go if you're making changes to this area. If 
you're not familiar with it, do take a look at the s9api design in Saxon:

http://www.saxonica.com/documentation/javadoc/net/sf/saxon/s9api/XPathCompiler.html

That involves three classes:

XPathCompiler contains the static context (variable and namespace 
declarations)

XPathExecutable is the thread-safe compiled and reusable XPath expression

XPathEvaluator contains the dynamic context (variable values, context item)

You can eliminate the XPathEvaluator by having a more complex evaluate() 
method on the XPathExecutable, e.g. one that supplies the variable 
values as a Map; but this doesn't reduce the overall number of objects 
involved, it just replaces the XPathEvaluator object with a Map object.

The other big design problem with an XPath API is the types used for 
variable values and for the evaluation result. With the JAXP API I get 
an enormous amount of support hassle caused by the lack of type safety 
in the way JAXP does this. In s9api I decided, despite the complexity, 
to introduce classes XdmValue, XdmItem, XdmAtomicValue etc to make the 
whole thing type-safe, and I don't regret the decision. (I also have 
XdmNode which abstracts over DOM, JDOM, XOM etc nodes.)

If you're designing a new XPath API in 2012 then I think it's essential 
to think about how it will support XPath 2.0.

Michael Kay
Saxonica