XOM API for Processing XML with Java

[Alan Gutierrez <alan AT blogometer.com>]

On Sep 28, 2007, at 7:48 PM, Robert Koberg wrote:

> On Fri, 2007-09-28 at 19:28 -0500, Alan Gutierrez wrote:
> > 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.

> Being curious... Why do you want to use XOM? I don't use it, but I  
> like
> to look at it. If it doesn't meet your needs, what makes it so
> compelling to push for changes to an obvious <don't-know-what-to-say
> perhaps="fascist | dictator"/>? Why not just dismiss it and use one or
> more of the many other alternatives?

I'm still waiting to see what ERH has to say. I would like to have my  
use case considered. It is common. XOM supports the event generation  
side of my use case but not the document generation side of my use  
case. It is difficult going forward because I feel I've answered  
questions and offered examples only to be asked more questions.  
However, I assume that ERH is merely allowing himself the time to  
make a decision, and has many other things to do.

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