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: Thomas Hicks <hickst AT theriver.com>
  • To: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Exposing XMLHandler
  • Date: Fri, 28 Sep 2007 08:16:37 -0700

At 01:20 AM 9/28/2007, you wrote:
Thomas Hicks wrote:

I understand your motives but sometimes you have to bend your
noble principles for pragmatism. I'm stuck, for example, trying
to integrate XOM (which I really like) into this 3rd party application.

And yet I still don't have details of what that application is or why anyone needs to do this. I try to keep the public API footprint minimal. No API is added without clear and compelling use cases. So far I haven't seen such a use case.

Two people have said they want this. Fine, but does anyone actually need it? That point has not been proven or quantified. More often than not when someone says they need a particular feature, there's already another way to do what they're trying to do.

Yes, I understand, which is why I described my use case (twice) and asked
directly if there was another way to do it. No response was forthcoming.

But, more to the point, I believe that my use case turns out to be
exactly the same as Mr. Guttierez's use case which turns out to be
a desirably common use case. It looks to me like our use case is
one that the designers of the XMLReader classes anticipated and
designed for.

Mr. Guttierez stated our argument best and so I quote him again:

Currently, the XOM library makes the assumption that SAX events are
generated by a parser. At it's most abstract, SAX events are
generated by an implementation of XMLReader that accepts an
InputSource to it's parse method.

Oddly, the XOM library provides a generator of SAX events,
SAXConverter, that does not fit this mold. It expects to be handed a
ContentHandler directly. It generates events by traversing an XOM
document, not by parsing a document, not by referencing an InputSource.

That is the use case for a public XOMHelper. For the class in the
spirit of SAXConverter of another library.

In my specific use case, I have a library that I developed with a
class called Binder, which is a container for an XML document that
translates between document object models. The easiest way to
translate between document object models it so play the document
object model as events into a ContentHandler and LexicalHandler pair
that will generate a document of a desired type.

Please note that, like Mr. Guttierez, I am also trying to use XOM
within the context of an existing library (3rd party in my case) and
that the interface to that library expects the exact same use case, the
same design pattern. XOM is the only library I have encountered
to date which can't be used with this design pattern.

Also, while I am not an XML expert, it looks to me like the XOM
source code already does the kinds of things that we are looking
for within the guts of the SAXConverter, XOMHandler, and
NonVerifyingHandler classes. Perhaps a look from your expert
eye might spot an easy refactoring that would allow our use case?
regards,
-tom









Archive powered by MHonArc 2.6.24.

Top of Page