XOM API for Processing XML with Java

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

I've had this one in the TODO list for some time now, but I still 
haven't figured out a way to do it that I really like, so I think I'm 
going to rule this out for XOM 1.0, and mark it a third party 
opportunity. :-)

However, I have had some interesting ideas on input filters that I 
think are cleaner than the filters in either DOM or JDOM, and will 
hit a really nice 80/20 point when you only want some of the content 
of the document, thus allowing lots of memory to be saved and perhaps 
avoiding unnecessary object construction.

In the next release of XOM it will be possible for the various 
makeElement/makeText/etc. methods in NodeFactory to return null. If 
they do, the Builder will simply not build that node. Thus a 
NodeFactory subclass can filter out anything it doesn't like. For 
example, a custom program could accept some elements and ignore 
others, or trim all white space before it's added to the tree.

This will require only minimal changes to the public NodeFactory API 
and none in the rest of XOM. It should be completely transparent to 
anyone who doesn't want to do this.

My current plans are to add two new methods to NodeFactory:

1. protected void endElement()
2. protected Text makeIgnorableWhiteSpace()

(In an unrelated move, I also plan to remove some confusing 
overloaded methods in NodeFactory that aren't actually called by the 
Builder, so the net effect should be a reduction in the size of the 
API.)

makeIgnorableWhiteSpace simply returns a Text node containing white 
space. The main purpose of this would be to allow the Builder not to 
build text nodes that contain ignorable white space, thus pruning the 
tree.

endElement() reports the end of an element. This would be useful when 
you want to adjust the filters depending on which element the builder 
is currently inside of. The patterns are very similar to those used 
in SAX.

By default returning null from startElement() will simply remove the 
start-tags and end-tags, but retain the element's content. A custom 
builder could easily change this behavior to remove everything inside 
the element. In DOM terms this is a skip rather than a reject. I am 
wondering if I've got this backwards. Perhaps by default returning 
null from startElement() should remove everything inside the element, 
and there should be some way to override this behavior? Thoughts?

Another open question are other uses of NodeFactory as a filter. In 
XOM today it is possible to change the name or namespace or 
attributes of an element as its built. Should it be possible to go 
further and replace an element with a processing instruction or vice 
versa? i.e. to substitute a different kind of node in the tree? All 
enabling this would really require is having the various makeXXX 
methods return Node instead of the more specific type. However, this 
might expand the type-checking in other parts of the code which is 
expensive, so I'd prefer not to do it unless there's a good use-case.
--

  Elliotte Rusty Harold
  elharo AT metalab.unc.edu
  Processing XML with Java (Addison-Wesley, 2002)
  http://www.cafeconleche.org/books/xmljava
  http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA