XOM API for Processing XML with Java

[Laurent Bihanic <laurent.bihanic AT atosorigin.com>]

Hi,

One more remark: With a single method it will be quite difficult to deal with 
namespaces, especially default namespaces since XPath has no concept of 
default namespace.

If you still think introducing an XPath object is not a good idea, you'll 
have to:
 - Add an argument to your query method to let the user provide prefix -> URI 
mapping information for namespaces and/or
 - Enhance the XOM Jaxen wrapper to support automatic context mapping for 
namespaces as JDOM org.jdom.xpath.JaxenXPath does. It solves the problem for 
non-default namespaces but not for default namespaces.

Not supporting any way to provide prefix -> namespace URI mapping would force 
XOM users to use XPath construct like "*[local-name()='bar']" rather than 
"foo:bar".

What do you think?

Laurent


Laurent Bihanic wrote:
> Elliotte Rusty Harold wrote:
> > Will these work if the classes are non-public? I'd like to hide the 
> > implementation and keep the JavaDocs as small as possible. I'm 
> > thinking just a single query method in the Node interface which might 
> > be backed by Jaxen but not directly expose it.
>
> Sure, it would work. Two remarks though:
>
> 1. Your query method is likely to take a String as argument, which means 
> the XPath expression will be compiled every time the method is called. 
> This is a serious performance problem as Jaxen often takes more time 
> compiling an expression than resolving it.
>
> 2. One method (e.g. selectNodes) may not prove sufficient because you 
> can not guarantee people won't use XPath functions in their expressions. 
> I think you should provide some way to apply expressions such as 
> "local-name(/msg:*/msg:entry/*[1])"
>
> Considering 1 + 2, I think you could add one or two convenience methods 
> to Node but for applications that intensively rely on XPath you should 
> provide a public XPath object. That way, you won't clutter the Node 
> inteface while allowing access to XPath powwer features (compiled XPath, 
> XPath variables, functions, ...).
> This is the way we did in JDOM and it proved quite useful in real 
> applications.
>
> Laurent