XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

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