XOM API for Processing XML with Java

[Thomas Hicks <hickst AT theriver.com>]

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