[XOM-interest] Exposing XMLHandler
Alan Gutierrez
alan at blogometer.com
Fri Sep 28 20:28:58 EDT 2007
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/
More information about the XOM-interest
mailing list