ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Kopecky <ja...@idoox.com>
Subject Re: Progressive DOM (was: Re: JDOM vs DOM)
Date Fri, 03 Nov 2000 11:40:00 GMT
 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