ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nelson, Christopher" <cnel...@synchrony.net>
Subject RE: JDOM vs DOM (was: Re: IRC chat log)
Date Thu, 02 Nov 2000 14:27:46 GMT
You betcha.

-----Original Message-----
From: Rich Johns [mailto:rjohns@vignette.com]
Sent: Wednesday, November 01, 2000 5:10 PM
To: soap-dev@xml.apache.org
Subject: Re: JDOM vs DOM (was: Re: IRC chat log)


I assume JDOM is public domain, no strings attached?

"Nelson, Christopher" wrote:

> I would like to weigh in on the side of JDOM.  I've been using it for
awhile
> and have also found it to be a very much more usable API for Java XML
> development than straight DOM.  Here's what I've seen several times: XML
> projects that use DOM generally have to build utility classes like
DOMUtils
> because DOM is so painful to use.  I think of JDOM as a standardized
> DOMUtils.  I've also found it fairly easy to convert between the two.
While
> I would agree that we do not want to force SOAP users to use JDOM, we do
not
> want to preclude the use of JDOM within the code where it makes sense to
use
> it.  I think we want to have interfaces points always expose DOM, but if
> some code uses JDOM internally to deal with XML, I don't think this should
> be forbidden.
>
> -----Original Message-----
> From: George I Matkovits [mailto:matkovitsg@uswest.net]
> Sent: Wednesday, November 01, 2000 2:48 PM
> To: soap-dev@xml.apache.org
> Subject: Re: JDOM vs DOM (was: Re: IRC chat log)
>
> I would like to add my 2 cents worth for JDOM
> 1.) I am  in complete agreement with Sanjiva about standards and the use
of
> SAX
> for handling 'large' payloads BUT
> 2.) JDOM: the DOM in JDOM does not mean it is based on DOM, it is NOT! It
is
> a
> Java wrapper around SAX/DOM classes and data structures.:-) JDOM is a very
> Java
> friendly API, I LOVE IT and there is also a good and comprehensive book.
> JDOM
> allows 'Java training wheel' access to XML for XML newbies like I (IMHO
much
> better then JAXP). I also noticed that there are many, many of us on the
> various
> xml related lists. Some combination of the two technologies (SAX and
JDOM),
> where JDOM access to SOAP APIs would be relatively easy, IMHO would be
very
> nice
> and would enhance Apache (IBM) SOAP's ease of acceptance over of that from
> the
> 'evil empire'. Also IMHO a JDOM friendly WSToolKit would add greatly to
the
> future acceptance  of Java as the 'defacto' Internet Business Environment.
I
> wish that Sun would also understand this. (-: They seem to have great
> difficulty
> in understanding the world outside the LAN cocoon unlike MS)
> Regards - George
>
> Sanjiva Weerawarana wrote:
>
> > > I think the concern with DOM (one which you put forth as well, if I
> recall
> > > correctly) is that it's rather a memory-hog, and is a bit too
> heavyweight
> > > for a lot of the use-cases.
> >
> > Yes, I put it forth too as a concern as the *output of serializers.*
> >
> > The problem with DOM is (mostly) the implementation. The APIs are
designed
> > to support "live" edits and monitoring, so the API force certain impl
> > requirements too. The real problem is the performance (memory usage)
> > of a full DOM impl *when one is not needed*. I would argue that Apache
> SOAP
> > is a case where a full live impl is not needed: once the envelope is
> parsed
> > its not going to change while a filter is operating.
> >
> > The solution IMO is to use SAX as appropriate and an efficient impl of
> > the DOM that is customized for our needs. What I am opposed to is
exposing
> > a non-standard API, even if it means a performance hit. Let's be
> realistic,
> > JDOM vs a good DOM will not mean a 50% performance difference not
> > reasonable sized messages. For large messages, the *only* real option is
> > to use SAX. Anything else is nuts.
> >
> > Sanjiva.

Mime
View raw message