XOM API for Processing XML with Java

["Bradley S. Huffman" <hip AT cs.okstate.edu>]

Elliotte Rusty Harold writes:

> I disagree. I'm not 100% clear on what you're proposing, but it seems 
> to add an extra class without adding any functionality. I don't see 
> how subclassers could use this to change the behavior of base URI 
> resolution on detachment, nor would I want to add such an unusual 
> piece of functionality. The use case feels too small to justify the 
> extra cl;ass.

I'm suggesting keep base URI *resolution* out of the core (nu.xom) completely
and put that functionality in a seperate class, the same way JDOM puts xpath
functionality in a seperate class instead of having a selectNodes method on
core classes like Element.

For the core, have very simple methods getActualBaseURI/setActualBaseURI which
return/set the value of the private variable actualBaseURI and that's it. They
do no resolution, and let the helper class handler all the dirty resolution
work.

This also means there would be no information lost when a element is detached.
You could always call getActualBaseURI on the element to find out where it
originally came from even if it's different than what base URI resolution
would return.

Brad