XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

On Jan 23, 2005, at 6:38 AM, Elliotte Harold wrote:

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

Do you need the namespace node or just it's URI for these things? In 
the latter case, you can just return the URI (wrapped into an element 
ala Nux) instead of a namespace node.

> 1. Just make XPathNamespaceNode a subclass of Node.
> 2. Wrap the namespace node in something that can be returned, like an 
> Element in a particular namespace.
> 3. Just make the query method return a List instead of a Nodes
> 4. Add an additional query method, probably in a separate package, 
> that does return a List.


How would an external XPath impl (without access to XOM's private 
backdoors) create an XPathNamespaceNode? I guess it can't, which 
suggests the design is rather limited.

More importantly, why bother with lots of new ill-fitting patchwork 
complexity (options 1-4) for something that only seems to be needed by 
0.01% of use cases? I hope there should be easier ways out here.