RE: Today's IRC log

[Jacek Kopecky <ja...@idoox.com>]

 Glen, 
 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.

 Yuichi,
 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
                               Idoox



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 [mailto:rubys@us.ibm.com]
 > > Sent: Tuesday, January 30, 2001 3:37 PM
 > > To: axis-dev@xml.apache.org
 > > 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
 > > 
 > 

Constants cleanup, hierarchical context namespace

[Jacek Kopecky <ja...@idoox.com>]

 Hello.
 I'm in a big hurry right now, so I'll be short.
 If nobody objects, I'll commit a major cleanup of Constants.java
(including moving it to org.apache.axis), and it will include changing
the context key constants to a hierarchical (a la Java
packages) namespacing so we get into less conflicts later on.
 Gotta go. 8-)


                            Jacek Kopecky
                               Idoox

Re: Today's IRC log

[Aleksander Slominski <as...@cs.indiana.edu>]

Jacek Kopecky wrote:

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

when you find such please let me know - when i was writing my XML pull parser i
could not find anything except Trantor XP (http://www.trantor.de/xml/) and KXML
(http://www-ai.cs.uni-dortmund.de/SOFTWARE/KXML/).

therefore i have modeled my API after them only making some small changes necessary
for low memory usage and perfomance in Java and C++ (for example i do not create
new StartTag for each element but i allow to recycle them, for details please see
http://www.extreme.indiana.edu/soap/PullParser/PullParser11/doc/api/xpp/package-summary.html).

i think that XmlReader
(http://msdn.microsoft.com/net/ecma/main.asp?Class=XmlReader)
can be built on top of a simpler pull parser that is doing simple pulling xml
events from stream.

it is not clear for me what are XmlReader bindings for Java and C++- could not find
them...

thanks,

alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika (1162-1241)