XOM API for Processing XML with Java

[Elliotte Harold <elharo AT metalab.unc.edu>]

Yesterday, while attempting to implement document subset 
canonicalization, I discovered that XOM may in fact need to expose 
namespace nodes from the XPath interface; i.e. queries like 
//namespace::* should perhaps not throw an exception. The specific issue 
that arose was that you don't actually get namespaces in a canonicalized 
document unless you explicitly select the namespace nodes. It's not 
enough to select the elements that use the namespace.

This may seem like an obscure issue, but it has implications further 
down the road for XML digital signatures, XML encryption, and everything 
that builds on top of that.

I'm really not sure how to proceed. This is going to require some 
experimentation. My current thought is that I will have to expose some 
sort of public XPathNamespaceNode class. I intend to keep this as 
minimal as possible. It will probably have getter methods for parent, 
prefix, and URI, and not much else. I'd like it to be one-way: i.e. 
namespace node knows its parent but parent doesn't know its namespace 
nodes, but this might require unnecessary and possibly confusing 
duplication of namespace nodes. Then again, maybe not. I have to 
experiment.

My suspicion is that the proposed XPathNamespaceNode is *not* a subclass 
of nu.xom.Node. A lot of code would need to be reconsidered if I were to 
add an additional base node type.

The alternative seems to be either reimplementing XPath inside 
Canonicalizer in a non-public way (i.e. canonicalizer wouldn't use quite 
the same XPath engine as the rest of XOM does) but that's really ugly; 
or moving Canonicalizer into the core package, which is a breaking 
change (though it could be made backwards compatible with a deprecated 
stub left behind in nu.xom.canonical). This is all really ugly, and once 
again I find myself wishing Java had friend functions. I'm going to try 
to come up make the namespace node approach work, and only consider 
these options if that fails.

If anyone has any other suggestions please holler. I really don't like 
any of the options I've come up with so far. When brainstorming, 
remember that at this point in time the XPath API is *not* sacrosanct, 
and it's absolutely possible to make changes to the API signature, 
package and class it belongs to, etc. Of course, I'd still like it to be 
as simple and straight-forward as possible for the simple and 
straight-forward cases. One possibility that's very much on the table is 
a separate XPath package that exposed more complex details like 
XPathNamespaceNode and XPathContext. This could also give us a place to 
put variable bindings, compiled XPath expressions, more engine 
indirection, and other things that have been asked for while still 
keeping the core API simple.

--
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