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 Wed, 01 Nov 2000 21:45:39 GMT
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