Skip to Content.
Sympa Menu

xom-interest - Re: [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: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] XOM 1.1: XPath
  • Date: Thu, 6 Jan 2005 14:28:21 -0800

Nux already has XPath 2.0 support for XOM, by virtue of supporting XQuery.
Also, saxon-8.2 implements the JAXP-1.3 XPath 1.0 API for XOM.
Saxon (and by its virtue, Nux) actually is standards compliant, mature and stable, whereas most other engines are not. I've stopped using Jaxen as an XPath engine a year or so ago - I found it too buggy and slow.

Both approaches offer essentially the same functionality wrt. XPath, and are based on the same underlying low-level code base (net.sf.saxon.xom.*)

The main differences of the two approaches are:

- Nux is easier to use and more seamlessly integrated with XOM than JAXP.
- JAXP is a recognized "standard" API whereas Nux is not.
- Nux also supports XQuery for XOM, whereas JAXP does not (this is via the same API because XQuery can be seen as a superset of XPath). For example, this is handy once one needs to go a little beyond the basic functionality that XPath provides.
- Nux exposes Saxon as the underlying engine via the Static/DynamicContext. The downside of that decision is that it is tied to Saxon. The upside is that Saxon's powerful configuration options are available to advanced user in their entirety. I found that to be more important than restricting the API to a lowest common denominator.In the end folks need versatile solutions to get real jobs done rather than APIs that merely "look nicely abstracted" at first glance. At least that's my experience. Hence the Nux API the way it is.

Wolfgang.

On Jan 6, 2005, at 1:47 PM, Elliotte Harold wrote:

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.

Makes sense. That's how Nux works.



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.

I didn't see much practical use for this either. Hence the automatic result sequence conversions documented with background info at

http://dsd.lbl.gov/nux/api/nux/xom/xquery/XQuery.html
http://dsd.lbl.gov/nux/api/nux/xom/xquery/ResultSequence.html


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.

Variables are important in practise for flexible usage and reusing compiled queries. I'm using a Map to bind and pass variables.



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.

A Map is simple enough and sufficient for all practical purposes.


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

In pracise queries over ParentNode (rather than any Node) are sufficient.

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?

You get an empty node sequence.

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 is a little akward work-around to this in the Nux XQuery class. It fakes a document and it's not a real problem. See the source code.


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

_______________________________________________
XOM-interest mailing list
XOM-interest AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/xom-interest





Archive powered by MHonArc 2.6.24.

Top of Page