[jdom-interest] DOMBuilder

[Kesav Kumar]

I have an idea for these kind of situations.  With the use of JDK1.3 Dynamic
proxy we can write a SAX1.0 and SAX2.0 bridge.  For most of the XML files
this kind of 1.0 and 2.0 bridge will work.  The major enhancements in SAX2.0
are namespaces and properties.  If your XML files doesn't have
namespaces(most of the xmls doesn't require) then you can easily think of
converting SAX1.0 events SAX2.0 events.  This idea may not satisfy all the
needs but for short term till all the technologies become stable you can use
this kind of conversion.

Kesav Kumar
Software Engineer
Voquette, Inc.
650 356 3740
mailto:kesavk at voquette.com
http://www.voquette.com


-----Original Message-----
From: Rosen, Alex [mailto:arosen at silverstream.com]
Sent: Monday, March 05, 2001 10:54 AM
To: jdom-interest at jdom.org
Subject: [jdom-interest] DOMBuilder


We are a 10 person team who have been using JDOM for the past 3 or 4 months.
I
just searched our codebase for DOMBuilder and found 4 instances.  (They are
using the Xerces DOMParser to parse an XML file into a DOM tree, and then
DOMBuilder to parse this into a JDOM tree.) This is a terrible waste of
resources, to be using DOMBuilder instead of SAXBuilder. I'd really, really
like to get rid of them.

3 of the instances are setting up Xerces-specific features on the DOMParser,
so
they can't currently be converted to use SAXBuilder. I mentioned this
problem a
few weeks ago, and got this response:

> "Rosen, Alex" wrote:
> >
> > Wouldn't it be nice if there were a version of SAXBuilder that took an
> > already-created XMLReader? Currently there doesn't seem to be a way that
I
can
> > turn on arbitrary SAX features that aren't supported by the SAXBuilder
API.
I'd
> > like to create an XMLReader myself, set it up however I'd like, and give
it
to
> > SAXBuilder.
>
> The reason we've elected not to do that is that many features of the
> XMLReader need to be set a certain way for SAXBuilder to function.  If
> you passed in an XMLReader we'd have to either take on faith that the
> features were set properly (not a good solution, as our feature
> selection may change over time without changing the API) or set the
> features to guarantee proper functioning (not good either, as it changes
> the passed-in parameter as a side effect).

Jason, I agree that neither of these is great. But the alternative is to
force
people to use DOMBuilder, which is even worse. I think this will slow the
acceptance of JDOM, as people either realize what a waste of resources this
would be, or don't realize and do it anyway, resulting in poor performance.

In the 4th instance, we were using DOMBuilder for no good reason at all. If
people do this accidentally, they'll also get poor performance and not think
highly of JDOM. If we make the change I suggest above, I also propose
changing
the name of the 3 DOMBuilder.build() methods that are listed as being for
debugging only, so it's harder to make this mistake. E.g. debugBuild() or
something. This will make it more obvious to avoid them, and if they are
deprecated and eventually removed, it will red-flag the cases where the code
can be made much more efficient by using SAXBuilder instead.

Alex Rosen
SilverStream Software

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com