Skip to Content.
Sympa Menu

xom-interest - [XOM-interest] XPath Namespace Nodes rethink

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] XPath Namespace Nodes rethink
  • Date: Sun, 23 Jan 2005 09:38:54 -0500

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





Archive powered by MHonArc 2.6.24.

Top of Page