XOM API for Processing XML with Java

[Alan Gutierrez <alan AT blogometer.com>]

On Sep 28, 2007, at 3:20 AM, Elliotte Harold 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.
>
> > And note that Mr. Guttierez resorted to some clever (and possibly
> > dangerous?) workaround. How many other programmers will
> > just do that, with possibly bad results? Perhaps you could take
> > another look at the problem and come up with a "safe",
> > XOM-oriented solution for us all.
>
> Right now I'm leaning toward figuring out a way to prevent exposing  
> the
> XOMHandler class from the user-supplied XMLReader. Barring that I may
> have to take another look at XMLHandler and make sure it's safe for  
> this
> sort of use.

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.

--
Alan Gutierrez | alan AT blogometer.com | http://blogometer.com/ | 504  
717 1428
Think New Orleans | http://thinknola.com/