[jdom-interest] XPath bindings?

[Alex Rosen]

> 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?
> 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.
>
> 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?
>
> Furthermore, what happens if the XPath expression is illegal?
> Is an exception thrown? If so what exception?

I agree that we should not rush to add these, if there are tough questions
that need to be answered. However, these don't strike me as particularly
tough questions. The methods should throw an exception if the returned type
of the XPath is not compatible with the return type of the method. If they
return no objects, the former method should return an empty list, while the
latter should return null. (I've never looked at Jaxen, but I imagine that's
what it does?)


> Grant I'm new to JDOM/Jaxen, but so far I've found them extremely easy
> to work with as is.  It's just adding selectNodes() to
> Element and Document
> stikes me as the same discussion of as the one about
> getChildTextNormalized().

Interesting point. I think it's a little different case, though. The
getChildText/Trim/Normalize methods all support particular styles of XML,
and are not useful for other styles. However, all users of XML need to
navigate their document, and can use XPath to do it, so these methods are
potentially useful to everyone. To me, it feels like the added usefulness in
this case is worth the disadvantage of expanding the API.

--Alex