XOM API for Processing XML with Java

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

Michael Kay wrote:

> Whether detaching/copying is an expensive operation depends on the
> implementation. I don't think it's particularly expensive in Saxon given a
> typical scenario where the number of in-scope namespaces rarely exceeds half
> a dozen. It's more expensive of course when you implement Saxon or any other
> XSLT/XQuery engine on top of XOM, because the models are mismatched. And I
> think that if people expect the namespace bindings of the new location to
> rule, they've simply not understood the model. 

If XOM were religious about implementing the model I think it would 
become unusable. For instance consider this:

Element root = new Element("foo:name", "http://www.example.org/";);
root.addNamespaceDeclaration("bar", "http://www.example.com/";);
Element child = new Element("child");
root.appendChild(child);

If were to follow the XPath model directly then what we'd have would be:

<foo:name xmlns:foo="http://www.example.org/"; 
xmlns:bar="http://www.example.com/";>
  <child xmlns:foo="" xmlns:bar=""/>
</root>

Every additional namespace would have to be declared on every element 
where it applied. I don't think that's what people want.

Remember, it's the principle of least surprise (or perhaps principle of 
fewest surprises) XOM is attempting to follow here, not the principle of 
no surprise. I don't think no surprise is possible when working with 
namespaces. :-)

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