XOM API for Processing XML with Java

[Robert Koberg <rob AT koberg.com>]

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?


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.
> 
> --
> Alan Gutierrez | alan AT blogometer.com | http://blogometer.com/ | 504  
> 717 1428
> Think New Orleans | http://thinknola.com/
> 
> 
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest