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