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: Robert Koberg <rob AT koberg.com>
  • To: elharo AT metalab.unc.edu, xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Exposing XMLHandler
  • Date: Fri, 28 Sep 2007 20:48:14 -0400


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





Archive powered by MHonArc 2.6.24.

Top of Page