[jdom-interest] suggested JDOM2 improvements
mike at saxonica.com
Fri Jan 20 02:45:19 PST 2012
>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!
>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:
That involves three classes:
XPathCompiler contains the static context (variable and namespace
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.
More information about the jdom-interest