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,
provides a single point for XPath expression evaluation, regardless of the target
object model, whether its dom4j, JDOM, DOM,
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.
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 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
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
is also provided.
Since many of the XPath axes can be defined in terms of each other (for example,
ancestor axis is merely a the
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.
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
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
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
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
(a subclass of
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
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);