[jdom-interest] XPath bindings?

[bob mcwhirter]

On Fri, 12 Oct 2001, Elliotte Rusty Harold wrote:

> At 11:32 PM -0400 10/11/01, bob mcwhirter wrote:
> >Howdy folks--
> >
> >Now that Jaxen is pretty darn compliant with regards JDOM (including
> >the namespace:: axis), I was wondering if we might want to spec out an
> >XPath binding.  I know the FAQ says maybe 1.1 would include XPath support,
> >and the JSR is for 1.0 only, but, XPath is seeming very useful to many
> >folks, and The Other Models seem to support it.
> >
> >Thus, I propose adding, to Document and Element the following:
> >
> >	public List selectNodes(String xpathExpr);
> >	public Object selectSingleNode(String xpathExpr);
> >
> 
> I like the first one. I object to the second. An XPath expression often
> returns more than one node. What does this method do if the argument
> in fact returns more than one node? 

It would provide you with the first one.  Not unlike Element.getChild(...)
which provides only the first child with the matching name.

> For that matter, what does it do if the XPath selects no nodes at
> all? In the context of JDOM, an XPath expression should always return
> a List.

For no-nodes, selectSingleNode(...) would return null.
For no-nodes, selectNodes(...) would return a List => List.size() == 0;

> Actually, now that I think about it, the first method's problematic
> too. An XPath expression may not return a list of nodes. It can return
> a boolean, a number, a string (which in XPath is NOT the same thing as
> a text node. Can JDOM even handle this?) or a result tree fragment. How
> do we handle these cases?

Sure, we have issues with the whole String/TextNode thing, but we do
the best we can, considering.

You're correct in that an xpathExpr may select non-node items, but
following the 80/20 rule, folks are mostly going to be selecting
nodes.  

I'm completely open to different method names, but I"m just thinking
that folks migrating from MSXML, dom4j, or other Object Models
are already comfortable for selectNodes(...).

> Furthermore, what happens if the XPath expression is illegal? Is an
> exception thrown? If so what exception?

This is JDOM, so some derivative of JDOMException to indicate 
an syntax error, with an interface mirroring the syntax
exception from jaxen/saxpath.  For low-level exceptions,
such as with SAXPath itself, possibly just pushing up the
actual exception, unless we only want JDOM exceptions exposes,
in which case, we'd wrap.

> I'm -1 on the current proposal. I think if these questions could be
> answered satisfactorily, then functionality similar to this would be
> useful. However, please don't rush into adding this until we can have
> full consideration of the various cases and implications of our decisions.

No rushing involved.  Your -1 forces this discussion, so let's iron this
out, and Get It Right.  

> One method I do think we could add to all the core classes (Element,
> Document, Attribute, etc.) in a very straight-forward way would be
> valueOf():

Yah, this would make the implementation of Jaxen a tad easier.

	-bob