[XOM-interest] Exposing XMLHandler
Alan Gutierrez
alan at blogometer.com
Thu Sep 27 19:24:11 EDT 2007
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/
More information about the XOM-interest
mailing list