XOM API for Processing XML with Java

[Alan Gutierrez <alan AT blogometer.com>]

On Sep 27, 2007, at 4:52 PM, Elliotte Harold wrote:

> Thomas Hicks wrote:
> > I used to work for Ralph Griswold, the creator of the SNOBOL
> > and Icon programming languages. Whenever someone would
> > program something particularly unusual or suspect Ralph would
> > remark "Well, we're just in the business of selling rope. If they
> > want to hang themselves, that's their business."
> >          cheers,
> >          -tom
>
>
> All I can say is, XOM's philosophy is very different. Not that you  
> can't
> hang yourself with it, but I want to make it very, very hard to do so.

As a user of XOM, I'd much rather that goal be stated in this fashion:

XOM strives to make it easy to create correct XML documents.

Which it does do. Not that the user is constantly on the lookout for  
new and better ways to hang himself. Rather, XOM treats conditions  
that would create an invalid XML document as exceptional conditions,  
where other libraries would not. It takes the guesswork out of  
creating XML documents. Back in the day, W3C DOM and the structures  
it would permit you to create, confused me to no end. XOM eliminates  
guesswork. It expresses XML tasks in straightforward Java.

Taking a step back.

XOM provides a means to create an XOM document by sending events to a  
ContentHandler and LexicalHadnler. The XOM implementations of  
ContentHandler and LexicalHandler are exposed. They are made  
available to client programs through an implementation of XMLReader.  
This is something that I've described.

However, because the XOMHandler is not available, the only way I can  
obtain the document is through the builder class.

The one position that everyone here is taking does not stand to  
reason. If I implement and XMLFilter that XMLFilter will be able to  
invoke methods on XMLHandler through the ContentHandler and  
LexicalHandler interfaces. If I were on the lookout for ways to  
create an incorrect XOM document via SAX, I have every opportunity to  
do so.

Currently, the XOM library makes the assumption that SAX events are  
generated by a parser. At it's most abstract, SAX events are  
generated by an implementation of XMLReader that accepts an  
InputSource to it's parse method.

Oddly, the XOM library provides a generator of SAX events,  
SAXConverter, that does not fit this mold. It expects to be handed a  
ContentHandler directly. It generates events by traversing an XOM  
document, not by parsing a document, not by referencing an InputSource.

That is the use case for a public XOMHelper. For the class in the  
spirit of SAXConverter of another library.

In my specific use case, I have a library that I developed with a  
class called Binder, which is a container for an XML document that  
translates between document object models. The easiest way to  
translate between document object models it so play the document  
object model as events into a ContentHandler and LexicalHandler pair  
that will generate a document of a desired type.

XOMHandler is already performing checks for integrity against calls  
from client software. The only change would be to permit a person to  
use the XOMHandler outside of the context of an XMLFilter.

Here are a few articles where this use of ContentHandler  
implementations is suggested:

http://www.xml.com/pub/a/2001/09/19/sax-non-xml-data.html
http://www.xml.com/lpt/a/1173
http://www.javazoom.net/services/newsletter/xmlgeneration.html

My Google-fu is a bit weak, because I know I've seen people use a  
ContentHandler to generate XML from a database or other programatic  
source more frequently than Google allows.

Here is the implementation that I kludged, by the way:

http://blogometer.com/svn/open/trunk/binder/artifacts/xom/java/com/ 
agtrz/binder/xom/XOMFactory.java

And here are implementations in Saxon, W3C DOM and DOM4J for comparison:

http://blogometer.com/svn/open/trunk/binder/artifacts/w3/java/com/ 
agtrz/binder/w3/W3Factory.java
http://blogometer.com/svn/open/trunk/binder/artifacts/saxon/java/com/ 
agtrz/binder/saxon/TinyTreeFactory.java
http://blogometer.com/svn/open/trunk/binder/artifacts/dom4j/java/com/ 
agtrz/binder/dom4j/Dom4JFactory.java

A ContentHandler that generates documents is a facility that is  
provided by these three libraries as well as JDOM.

XOMHelper is almost there. I understand that the (much appreciated)  
rigor of XOM means that Mr. Harold won't go slapping public on a  
class at the first user request, but I do ask that he consider this  
carefully.

XOMHelper is almost public. The ContentHandler and LexicalHandler are  
both exposed. The getDocument method is encapsulated in the Builder  
parse method, but returns directly to the user. I'd imagine that if  
you were to give the user another foot of rope, you might imagine  
that the user would call getDocument before calling endDocument, but  
as it stands, that is a series of events that can transpire with a  
faulty implementation of XMLFilter.

In essence, I ask that XOM remove the assumption that SAX events are  
created by parsing an InputSource. There are plenty of valid  
applications for generating SAX events by other means.

--
Alan Gutierrez | alan AT blogometer.com | http://blogometer.com/ | 504  
717 1428
Think New Orleans | http://thinknola.com/