We use an Apache-style open source license which is one of the least restrictive licenses around, you can use jaxen to create new products without them having to be open source.
After implementing an XPath engine for both dom4j and JDOM, and attempting to keep them both in sync, it was decided that factoring out the commonality would be a Good Thing. Thus, jaxen provides a single point for XPath expression evaluation, regardless of the target object model, whether its dom4j, JDOM, DOM, XOM, JavaBeans, or what not.
jaxen is better than werken.xpath specifically because it better handles XPath expressions, and syntax error reporting. Additionally, since jaxen is a unified code-base, developer effort isn't split between maintaining the dom4j version and the JDOM version. More hands working on the same project reduces bug count.
jaxen may be perceived to be better than other XPath technologies since it provides a single cohesive API for evaluating XPaths against multiple object models. Learn the jaxen API, and apply it to dom4j, JDOM, XOM or DOM trees in exactly the same way.
Also, since jaxen works against an adaptor which provides InfoSet access to arbitrary object models, it should be possible to build even larger tools in terms of jaxen, to work with multiple models. For example, an XQL engine could be developed, which would automagically work with all models already supported by jaxen.
jaxen itself is based upon SAXPath, which is an event-based model for parsing XPath expressions.
jaxen supports XPath 1.0. It does not support XPath 2.0. XPath 2.0 is a very different spec with many things to recommend it and a few things not to like as well. However XPath 2.0 is not compatible with XPath 1.0. It is far from a simple upgrade from XPath 1.0. It has a very different data model, that might well require significant revisions to jaxen's internal data structures, and possibly a very different API as well.
The current release plan focuses exclusively on XPath 1.0 compatibility. Perhaps one day someone will make a branch or fork of jaxen that supports XPath 2. However, this would be a significant undertaking, and so far little interest in this has been shown.
The only thing required is an implementation of the interface org.jaxen.Navigator. Not all of the interface is required, and a default implementation, in the form of org.jaxen.DefaultNavigator is also provided.
Since many of the XPath axes can be defined in terms of each other (for example, the ancestor axis is merely a the parent recursively applied), only a few low-level axis iterators are required to initially get started. Of course, you may implement them directly, instead of relying upon jaxen's composition ability.
The DocumentNavigators provided with jaxen would be used by themselves, without the XPath evaluation engine, to provide univeral access to many object models for other technologies.
jaxen has been embedded directly into dom4j and XOM 1.1 to provide easy XPath evaluation directly from your documents. Additionally, it's being integrated into David Megginson's NewsML Framework. Tom Copeland's PMD static code analyzer uses jaxen to query Java code structures using XPath.
The XPath expression that selects elements or attributes in a namespace looks exactly the same as it does in any other XPath context; that is, use prefixed names where the prefixes are bound to the namespace URIs. For example,
However, because a Java program is not an XML document, it is also necessary to bind the prefixes to the appropriate namespace URIs through a NamespaceContext object. For example, this code sets up and then executes the above query:
XPath xpath = new DOMXPath("/foo:bar/@xlink:href", nav); SimpleNamespaceContext nsContext = new SimpleNamespaceContext(); nsContext.addNamespace("pre", "http://www.foo.org/"); nsContext.addNamespace("xlink", "http://www.w3.org/1999/xlink"); xpath.setNamespaceContext(nsContext); List result = contextpath.selectNodes(document);
As a shortcut, you can simply add a namespace binding to the XPath expression's current context using the addNamespace method:
XPath xpath = new DOMXPath("/pre:root"); xpath.addNamespace("pre", "http://www.example.org/"); List result = xpath.selectNodes(root);
If the namespace context does not contain a binding for a prefix that is used in the XPath expression, an UnresolvableException (a subclass of JaxenException is thrown when you attempt to evaluate it.
The same way you do for elements and attributes that are in prefixed namespaces. That is, you use a prefix in the XPath expression and bind the prefix to the namespace URI. You do this even if the document you're querying uses unprefixed namespaced qualified names. In XPath 1.0, all unprefixed names are unqualified. There is no requirement that the prefixes used in the XPath expression are the same as the prefixes used in the document being queried. Only the namespace URIs need to match, not the prefixes.
For example, this code fragment queries the document [<root xmlns="http://www.example.org/"/> using the XPath expression /pre:root:
Element root = doc.createElementNS("http://www.example.org/", "root"); doc.appendChild(root); XPath xpath = new DOMXPath("/pre:root"); SimpleNamespaceContext context = new SimpleNamespaceContext(); context.addNamespace("pre", "http://www.example.org/"); xpath.setNamespaceContext(context); List result = xpath.selectNodes(root);
Alternately, using the shortcut:
Element root = doc.createElementNS("http://www.example.org/", "root"); doc.appendChild(root); XPath xpath = new DOMXPath("/pre:root"); xpath.addNamespace("pre", "http://www.example.org/"); List result = xpath.selectNodes(root);