Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XPath support for XOM

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Laurent Bihanic <laurent.bihanic AT atosorigin.com>
  • To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • Cc: XOM-interest <XOM-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] XPath support for XOM
  • Date: Tue, 29 Apr 2003 17:26:03 +0200


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




Archive powered by MHonArc 2.6.24.

Top of Page