ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hui <b...@724.com>
Subject RE: JDOM vs DOM (was: Re: IRC chat log)
Date Wed, 01 Nov 2000 16:20:48 GMT
after reading this thread, i quickly go check out the JDOM API. i wonder
what is the primary cause of the memory consumption of the W3 DOM API. is it
just a implementation issue or the DOM API implies intensive memory  usage?

comparing JDOM and DOM, i don't see DOM should take particular more memory
than JDOM, except that DOM does introduce more classes and functionalities,
in which i can believe there is a overhead. I must agree with Sanjiva that
there is a *strong* value of exposing standard API between software
components. i would trade "some" performance loss in exchange of standard
protocol/interface for better interoperability. of cause, the level of
"some" is left to the application to justify. i see JDOM is an excellent
alternative for internal XML data processing, think of it as another java
data model toolkit that is compatible with XML and you may feel better that
way. (isn't that implies another feature "Fastest XML-Java Engine in the
Industry" in your product fact sheet :-)

ben

-----Original Message-----
From: Glen Daniels [mailto:gdaniels@allaire.com]
Sent: Wednesday, November 01, 2000 10:31 AM
To: 'soap-dev@xml.apache.org'
Subject: RE: JDOM vs DOM (was: Re: IRC chat log)



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.

I can really see going either way with this.  If we're going to do SAX
parsing, we need *some* kind of internal representation in which to store
things as the parser moves over them.  Using DOM for this would be OK, but
potentially less efficient than we might be with another structure.  You do
get standard programming APIs and tools, but then again it wouldn't be that
hard to put a DOM wrapper around something like JDOM also.

I'm not personally religious about this issue, and don't have enough solid
experience in this area to judge.  I'd be very interested in the opinions of
other parts of the XML community as well.

--Glen

P.S.  Glad your son's OK!

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Wednesday, November 01, 2000 4:57 AM
> To: soap-dev@xml.apache.org
> Subject: JDOM vs DOM (was: Re: IRC chat log)
> 
> 
> Sorry I missed this chat too; had to take my son to the doc 
> (he hit his
> leg and it may have been fractured .. it wasn't). 
> 
> I read the logs and I see discussion of using JDOM instead of DOM as
> the tree API. I would like to register my early and strong opposition
> to it .. DOM is a standard API as is SAX and I would like to use those
> two. This allows the use of pretty much arbitrary XML tools (like 
> alternate parsers for example as has been brought up) and I'm opposed
> to precluding those in favor of a non-standard (albeit more programmer
> friendly) API. This is the life of standards playing .. whether you
> like it or not you gotta do it. Picking and choosing (or embracing and
> extending) would put us in the camp of the evil empire.
> 
> I have some recollection of hearing of a religious war on the JDOM/DOM
> topic on the xerces list .. if there are any veterans of that war here
> maybe they could give us the summary (of their side :-))?
> 
> Sanjiva.
> 
> ----- Original Message ----- 
> From: "Glen Daniels" <gdaniels@allaire.com>
> To: <soap-dev@xml.apache.org>
> Sent: Tuesday, October 31, 2000 5:05 PM
> Subject: IRC chat log
> 
> 
> > 
> > Here's today's IRC log.  I'm working on the stuff we 
> mentioned, though I
> > need to push it back a day or two due to local insanity here.
> > 
> > I'll mail my prototype tomorrow (need to iron out a couple 
> of bugs from the
> > last round of changes).
> > 
> > Glen Daniels
> > Allaire Corp
> > Engineering Manager
> > http://www.allaire.com/
> >                                 Building cool stuff for web 
> developers
> > 
> > 
> > 
> 

Mime
View raw message