XOM API for Processing XML with Java

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

Elliotte Harold writes:

> Bradley S. Huffman wrote:
> 
> > 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?
> 
> 
> You may be right. Option 1 might make more sense. My initial effort to 
> produce a separate XPath package was a big mess because the XPath engine 
> used lots of package protected parts. (Again, I really, really wish Java 
> had friend functions, but we have to work within the constraints of the 
> language.)
> 
> Making XPathNamespaceNode a real node would probably make the XPath code 
> noticeably simpler. My only real concern is what happens when 
> XPathNamespaceNode objects get passed to methods that aren't expecting it.

insertionAllowed() should handle that. Consider what happens when you pass
a Attribute to insertChild? Plus I suggest, at least initially throwing a
exception on detach(), and not having any public constructors
or setters to further ensure it won't adversely effect the rest of the
API. 

> I wonder how many such methods are there really? insertChild in 
> ParentNode, Document, and Element. XOMTestCase. What else? Maybe some of 
> the samples package. Anything else? Too bad javadoc doesn't produce a 
> list of all the methods a given object is passed to.

Serialize has one method, and SAXConverter has one.

Brad