XOM API for Processing XML with Java

[Alan Gutierrez <alan AT blogometer.com>]

On Sep 28, 2007, at 6:03 PM, Elliotte Harold wrote:

> Alan Gutierrez wrote:
> > Please reread the message that I sent yesterday. I put a good deal  
> > of time into it. In it you will find the use case, a very common  
> > use case, that calls for an independent and public ContentHandler  
> > and LexicalHandler implementation that builds an XOM document. You  
> > will find a link to examples of the independent and public  
> > ContentHandler and LexicalHandler implementations that generate  
> > W3C DOM, Saxon TinyTree, and DOM4J.
>
> I have read it and looked at some of your references, but it will  
> take time. I can't give a quick answer. From what I've looked at so  
> far, I'm not convinced you actually need what you say you need. It  
> may be enough to use a custom XMLReader instead, which is what XOM  
> is designed to do. The question I ask is two fold:
>
> 1. What does exposing XOMHandler let you do?
>
> 2. Is there no other way to do that within the existing API?
>
> One of the design principles of XOM is that there's only one way to  
> do it. :-)

Offhand, I'd have to say that Mr. Hicks pulled out the salient point  
from my last message. That XOM implies half of the use case,  
generating events by means other than parsing.

What I specifically want to do cannot not be done within the exiting  
API. I want to generated an XOM document from an event generator that  
is not an XMLReader. It shouldn't be an XMLReader. Because an  
XMLReader reads XML. The generator I wish to use is one that accepts  
a ContentHandler and LexicalHandler and sends events to them  
directly. As XOM stands, the only way to do this is to create an  
XMLReader. This XMLReader would not "parse" anything. It would ignore  
the InputSource.

XMLHandler could be moved into the converter package with SAXConverter.

The design principle that there should be only one way to do it is  
not violated. Thus exposed XMLHandler would still be a very well  
behaved and well designed ContentHandler and LexicalHandler  
implementation. It would work interchangeably  with classes analogous  
to SAXConverter in other libraries.

Builder is a facade that makes the creation of XOM documents simple  
and hides the details of XMLReader invocation. It does not allow for  
the creation of XOM documents through SAX event streams that are not  
generated by parsers. One could adhere to the Builder model (it  
wouldn't work my application) but then you'd be modeling event  
generation from in memory DOM or database query as parsing, which is  
incorrect.

To answer your questions:

Exposing XOMHandler permits me to easily generated an XOM document  
from SAX events. One would be able to create the XOMHandler and feed  
it to a class like org.jdom.output.SAXOutputter.

http://www.jdom.org/docs/apidocs/org/jdom/output/SAXOutputter.html

It has always been my understanding that ContentHandler and  
LexicialHandler are allowed to exist outside the context of  
XMLReader. Cocoon certainly thinks so, since it builds pipelines  
without nesting XMLFilters. I've taken to building SAX pipelines that  
are XMLFilter free based on an understanding of SAX as an event  
mechanism not a parsing mechanism.

The only other way to accomplish this DOM translation library would  
be to serialize from one DOM and parse to create the other DOM, or to  
inject a special case for XOM that would serialize rather than  
translate using SAX and events.

XOM sees events as the output of parsing and hides events inside a  
parsing facade builder. Events are a separate beast.

Albert Einstein
Everything should be made as simple as possible, but not simpler.

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