Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Shemp: an XMLFilter for use with XOM

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • To: John Cowan <jcowan AT reutershealth.com>, xom-interest AT lists.ibiblio.org (Xom Interest)
  • Cc:
  • Subject: Re: [XOM-interest] Shemp: an XMLFilter for use with XOM
  • Date: Wed, 18 Jun 2003 09:11:55 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page