ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George I Matkovits <>
Subject Re: JDOM vs DOM (was: Re: IRC chat log)
Date Wed, 01 Nov 2000 19:48:10 GMT
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.

View raw message