XOM API for Processing XML with Java

["Michael Kay" <mike AT saxonica.com>]

> Namespaces are an ugly conceptual misfit, no matter how you approach 
> them. Possibly I could avoid the problems by going back to 
> the beginning 
> and working namespaces into the Element class, so it use Namespace 
> objects instead of strings, and modeling namespaces in scope 
> like XPath 
> does rather than namespaces declared like XOM does. But the 
> memory cost 
> still worries me. Much worse is the question of how to handle 
> namespaces 
> in scope as elements are moved around, disconnected from 
> their parents, 
> and inserted into new documents. 

Modelling "inscope namespaces" rather than "declared namespaces" gives much
more predictable results from a user perspective: when elements are
disconnected from a tree and added to another tree, they take all their
inscope namespaces with them.

Of course, it's a challenge for the implementor, but if something is easier
for users and harder for implementors, then it's the right thing to do.

Modelling inscope namespaces as first-class nodes is a different question.
Most of the cost in implementing the XPath model of namespace nodes is not
because they're modelling inscope namespaces (rather than declared
namespaces), but because the nodes for each element have distinct identity,
document order, and parentage.

Saxon stores namespace declarations internally, but presents an
inscope-namespaces view to the user.

Michael Kay