ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <sanj...@watson.ibm.com>
Subject Re: JDOM vs DOM (was: Re: IRC chat log)
Date Thu, 02 Nov 2000 01:29:31 GMT
I'm not talking about internal use within a filter .. I'm talking about
the API that's defined for a single filter; the interface that's being
defined.

Inside a specific filter anyone can do anything they want, of course.

I have not programmed with JDOM yet. I have no doubt in my mind that
its an easier to program with API vs. the DOM, which is pretty damn near
unusable without soemthing like DOMUtils. Yes, JDOM may be viewed as a
"standard" DOMUtils, and as such is a very good thing. However, that
implies that you support my view that the interfaces should be defined
using standard APIs (DOM and/or SAX) and that the implementations can
use whatever they want.

Sanjiva.

----- Original Message -----
From: "Nelson, Christopher" <cnelson@synchrony.net>
To: <soap-dev@xml.apache.org>
Sent: Wednesday, November 01, 2000 4:45 PM
Subject: RE: JDOM vs DOM (was: Re: IRC chat log)


> 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