Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Exposing XMLHandler

xom-interest AT

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Alan Gutierrez <alan AT>
  • To: rob AT
  • Cc: elharo AT, xom-interest <xom-interest AT>
  • Subject: Re: [XOM-interest] Exposing XMLHandler
  • Date: Tue, 23 Oct 2007 15:51:00 -0500

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

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.

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 | | 504 717 1428
Think New Orleans |

Archive powered by MHonArc 2.6.24.

Top of Page