axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Kopecky <>
Subject RE: Today's IRC log
Date Tue, 06 Feb 2001 11:14:16 GMT
 Thanks for mentioning PDOM. 8-)
 Even though I first thought PDOM would be built on top of SAX and be
able to exit to SAX, the more I think about using a Pull parser the
more I like it _and_ I would suggest that whatever PDOM is built upon,
it would exit into a pull parser.

 I know you're concerned about PDOM not being implemented yet, and I
suggested an easy implementation/usage path:
 Since PDOM is basically a DOM with an exit option, it can easily be
built on DOM and I could provide such a wrapper for a normal DOM
implementation in about a week (considering my current workload) but
I'd like to use some standard Pull XML Parser API.  

 Does anybody know of a pull XML parser API that would at least aspire
to become standard (as IMHO SAX successfully did) ?

                            Jacek Kopecky

On Tue, 30 Jan 2001, Glen Daniels wrote:

 > Sam:
 > My concern with SAX is that the processing model can (and should, IMO, to
 > get the real bonus) be *completely* different from the DOM model.  I would
 > want to build the Handler framework differently - basically have each
 > Handler register for the types of stuff it's interested in, and then a piece
 > of our infrastructure acts as the SAX event handler, feeding the pieces to
 > the appropriate Handlers as they are read.  This has some problems with
 > multi-ref accessors, as we discussed in the chat, so there would still need
 > to be *some* kind of generated in-memory message model.
 > I can see us, for now, making the DOM completely isolated behind a canonical
 > Message API.  That solves the "option, not a requirement" problem.  Then, if
 > we have time, I would suggest we consider a PDOM approach, with a thread
 > spinning off SAX events to a middle layer which presents the canonical
 > Message API upwards to the Handlers.  When they ask for stuff that hasn't
 > yet been reached in the stream, the PDOM layer runs through the SAX stream,
 > caching everything until it gets to the desired stuff.  This would allow us,
 > later, to hook the SAX events to other sinks when appropriate.
 > In any case, this should all be hidden if possible.
 > --Glen
 > > -----Original Message-----
 > > From: Sam Ruby []
 > > Sent: Tuesday, January 30, 2001 3:37 PM
 > > To:
 > > Subject: Re: Today's IRC log
 > > 
 > > 
 > > +1.  I generally agree with everything that was said.
 > > 
 > > A few comments:
 > > 
 > > (1) I agree that rewrites are inevitable, as some point in 
 > > the future we
 > > will know more than we do now.  But that is no excuse to 
 > > ignore things that
 > > we DO know now.
 > > 
 > > (2) while in the general case, there may be some handlers or even some
 > > specific messages that are difficult/impossible to handle without
 > > significant lookahead, coding everything to the general case will make
 > > everything uniformly slow.  Put in a more tangible way - inevitably
 > > somebody will develop and publish benchmarks claiming that 
 > > their version of
 > > SOAP is better performing and more scalable than ours.  Such 
 > > benchmarks are
 > > likely to be very simple messages, though possibly large, 
 > > messages arriving
 > > at a fast rate.
 > > 
 > > For these reasons, I believe that DOM should be an option, not a
 > > requirement.  In the fullness of time, SAX and/or pull may 
 > > also be valid
 > > options, though in order to validate the architecture, at least one
 > > alternative that is significantly different than DOM (more so 
 > > than simply
 > > JDOM is) should be implemented.
 > > 
 > > - Sam Ruby
 > > 

View raw message