Skip to Content.
Sympa Menu

xom-interest - [XOM-interest] XOM 1.1: XPath

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: [XOM-interest] XOM 1.1: XPath
  • Date: Thu, 06 Jan 2005 16:47:11 -0500

The second major feature for XOM 1.1 is XPath. To some extent this already available through NUX, Jaxen, SAXON, etc. However, I'd like to build in basic XPath 1.0 support to XOM. However, there are some mismatches between XPath and XOM that make this tricky:

1. XPath has namespace nodes. XOM doesn't.

I could either create a special Namespace class, to be used just for XPath; or I could simply rule out queries that return namespace nodes, and throw an exception if one is encountered. I'm leaning toward the latter, but not strongly. I might be convinced otherwise.


2. XPath functions tend to return numbers, booleans, strings, and node-sets. In XOM this would need to be expressed as returning a list of objects, or some such, which I really don't like for reasons of type safety.

My thought here is to simply restrict all queries to location paths and multiple location paths separated by |. (I wish there were a name for this.) Is there an alternative to this? Would it be useful to allow other XPath expressions that return node-sets, even if they're not full location paths?


3. How are XPath variables bound?

My current thinking is that variables simply will not be bound. XOM will treat an XPath expression that contains a variable exactly as any XPath engine would treat an XPath expression that contains an unbound variable.


4. How are namespace prefixes bound? (especially important for the default namespace)

This one's tougher because, unlike the variable binding, XOM really can't just punt on this. It has to provide some sort of binding mechanism. Possibilities:

1. A Map
2. A custom type-safe map of namespace bindings
3. An element that carries all the relevant prefix bindings, not necessarily the element being queried. This is sort of ugly, but does perhaps allow for more reuse of code.

Also a possibility is that the query will simply inherit the namespace bindings of the context node, but even if XOM does this, it still wouldn't handle the default namespace. We need some way to pass in a list of bindings with the query for queries that use namespace prefixes.

The final question is what the API will look like. My current thinking is that this will be two methods added to the Node class that look like this:

public Nodes query(String xpath) throws ToBeDeterminedException
public Nodes query(String xpath, Map namespaceBindings)
throws ToBeDeterminedException

The context node for each query would simply be the node on which the query method was invoked.

Also worth exploring: what happens if this is invoked on a disconnected node? e.g. what happens if we try to use XPath to get the parent node of an Attribute object with no parent? For this case, I can probably just return an empty Nodes. However, is the possibility of nodes that do not belong to any document likely to break some implicit assumption in XPath somewhere?

There are probably other issues, but those are the big ones I see. Thoughts? Ideas? Comments? Anything else I'm missing?

--
Elliotte Rusty Harold elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim





Archive powered by MHonArc 2.6.24.

Top of Page