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: elharo AT metalab.unc.edu
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Exposing XMLHandler
  • Date: Fri, 28 Sep 2007 19:28:58 -0500


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/






Archive powered by MHonArc 2.6.24.

Top of Page