Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Exposing XMLHandler

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Alan Gutierrez <alan AT blogometer.com>
  • To: Elliotte Harold <erharold AT gmail.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Exposing XMLHandler
  • Date: Thu, 27 Sep 2007 18:24:11 -0500


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/






Archive powered by MHonArc 2.6.24.

Top of Page