XOM API for Processing XML with Java

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

> > What's the problem with #1?  If you offer no public constructors or
> > setters, and don't allow it to be detached what current code would
> > need to be reconsidered?
> 
> They're a lot of methods that take nodes as arguments 
> throughout the API 
> ranging from ParentNode.insertChild() to 
> XOMTestCase.assertEquals(). I 
> don't really relish going through the whole API looking at each and 
> every one of them to figure out what would happen if an 
> XPathNamespaceNode were passed to it. :-(

I understand the motivation, but all my experience of software development
says that if you avoid doing the right thing because it feels like too much
work, you soon regret it.

The more people come up with different ways of modelling namespaces, the
more convinced I become that James Clark's "namespace node" model is the
simplest and most elegant way of doing it. The main problem with it is that
it requires a lot of cleverness to implement efficiently: but it can be
done.

Michael Kay
http://www.saxonica.com/