ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: Progressive DOM (was: Re: JDOM vs DOM)
Date Sat, 04 Nov 2000 07:17:49 GMT
This combined DOM/SAX approach makes a lot of sense - it gives the advantages of
efficient SAX parsing for the body while retaining the flexibility of working with a
(J)DOM for the headers. The idea of building a DOM for the whole message and then
passing the body portion off to a handler (which would then need to walk the DOM and
convert all the values to usable form) had me concerned about performance, but this
way the message handler can decide how to process the body itself. Those who want to
work with a DOM-type model for the body can easily build one from the SAX event
stream, while others can handle value conversions on the fly and avoid some overhead.

I personally prefer JDOM to DOM but haven't seen any actual comparisons of
performance (CPU and memory usage). JDOM *is* compatible with DOM in the sense that
it supports two-way conversion. I don't know if this support is complete, but it
offers the possibility of using JDOM internally while still being able to provide a
DOM representation if that's really what someone wants to work with.

  - Dennis

Jacek Kopecky wrote:

>  What I meant by saying SOAP is not a stream process was that I think
> that nothing but the body can be usefully processed as a stream. If
> anybody shows me a useful and elegant usecase for a big header, I'll
> rethink this, but I myself cannot easily see the need for streaming
> the header information.
>  Of course the body of a message can be anything, there SAX might be
> very appreciated and that's why I wanted the function that terminates
> building of the DOM and hands the SAX stream to the handler.
>  I don't like the idea of building the whole server around SAX, it
> doesn't fit the server's needs. I also don't think SAX and DOM model
> would get along well in one architecture, so if you want a specific
> server that handles the _whole_ message as a SAX, you can build one
> yourself (reusing some of the Apache code). The "terminate and give me
> SAX" extension I suggested would nicely allow for most of the
> usecases.
>  Or wouldn't it? I'm interested in more discussion on this topic.
>  Regards,
>
>                             Jacek Kopecky
>                                Idoox
>
> On Fri, 3 Nov 2000, Sanjiva Weerawarana wrote:
>
>  > This same problem exists in an XSLT processor .. start doing the transform
>  > without waiting for the entire doc to come in. They called it incremental
>  > DOM I think. I believe Xerces has some such notion too.
>  >
>  > The implication of your statement is that we would use the DOM APIs
>  > in the interfaces and use an implementation that fills the tree
>  > incrementally instead of a priori. When I read the last IRC discussion
>  > (was there one after Tuesday; if so I forgot to note it down) didn't
>  > imply SAX is out. Yes, SOAP RPC is not a stream process, but SOAP
>  > messages are carrying some XML to some recipient; there's no way to
>  > know a priori whether that's a stream process or not. As such, I would
>  > prefer to see a model where *both* SAX and DOM are in and at say
>  > deployment time the choice is made as to what should be delivered to
>  > the next step. Is that out of the question?
>  >
>  > Sanjiva.
>  >
>  > ----- Original Message -----
>  > From: "Jacek Kopecky" <jacek@idoox.com>
>  > To: <soap-dev@xml.apache.org>
>  > Sent: Friday, November 03, 2000 4:59 AM
>  > Subject: Progressive DOM (was: Re: JDOM vs DOM)
>  >
>  >
>  > > Hello all. 8-)
>  > >  I think we agreed in the IRC discussion that SAX is not the way to go
>  > > since handling SOAP is not a stream process.
>  > >  What I envision is that we build on DOM (maybe using JDOM if it's
>  > > really a "universal DOMUtils") and when it's really needed, we can
>  > > plug in some other DOM implementation built progressively from a SAX
>  > > stream.
>  > >  This Progressive DOM would keep what has been parsed so far, but it
>  > > would not parse more than needed and it could provide us with the
>  > > SAX form of the rest. A little example:
>  > >
>  > > <root>
>  > >  <a/>
>  > >  <b>
>  > >   <c/>
>  > >  </b>
>  > > </root>
>  > >
>  > >  The PDOM gets an "element <root> started" SAX event and it would know
>  > > we have an XML with its document element <root>. When
>  > > getFirstChild() is called the PDOM consumes the following event,
>  > > "element <a> started" and it would return the node. If every more
>  > > complex method is build on such progressive calls as
>  > > getFirstChild() is, we could have excellent efficiency if we only need
>  > > the first header in a huge message.
>  > >  Anyway, I can't see any reason for huge headers, only huge bodies
>  > > make sense. To handle this nicely the PDOM could have a method that
>  > > would terminate the PDOM existence _and_ (this seems important) we
>  > > could get the SAX stream from now (or from some point in the XML
>  > > file). So we would parse what we need and the final handler (who would
>  > > have to know it's the final one) could work efficiently with SAX.
>  > >
>  > >  The first thing to implement here would be an API that lets us do the
>  > > last step on a normal DOM. Thus we could use a DOM and finish with SAX
>  > > when needed and the switch to PDOM would then be seamless.
>  > >
>  > >  Any suggestions? Any kind of PDOM already implemented / in progress?
>  > >
>  > >                             Jacek Kopecky
>  > >                                Idoox
>  > >
>  > > P.S: hope it was clear enough, I sometimes have problems with
>  > > expressing myself in an overly complex way, see? 8-)
>  > >
>  > >
>  > >
>  > > On Wed, 1 Nov 2000, Sanjiva Weerawarana wrote:
>  > >
>  > >  > 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