Re: JDom [terminology]

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

hi,

in my opinion SAX is push-based and trying to make it pull-able is not a good
idea. if you use real pull based XML parser you do not need extra thread. using
extra thread for each input to buffer pushed events can get quite complex (and
not good for performance).

i think that better solution is to use pull parser to scan input. and then for
some parts of input create J/DOM tree or SAX input stream. from my experience
pull parser api is generally even easier to use than J/DOM when writing
deserializer - you do not need to walk in the tree but you ask for next expected
event (start tag, element content, end tag).

so then you have the model:

---> bytes on the wire
  ----> real XML pull parser
    [ optional ] ---> J/DOM tree or SAX event stream for selected parts of input

      ---> Java objects (maybe, but not always (eg intermediary))
        ---> make the call (usually)
         ---> Java objects
           --->bytes on wire


thanks,

alek

Glen Daniels wrote:

> There's a bit more detail to the "pull parsing" model.  What we envision
> happening is this.  One thread starts parsing the XML as SAX events, and
> building up a JDOM-like object model.  So basically this guy just creates an
> empty Document "proxy" object, with an almost-empty root Element proxy
> object inside it.  At this point the SAX "StartElement" event for the root
> element has occurred on the parsing thread, and then the thread suspends.
>
> Now when someone calls "getChild('foo')" on the proxy Element (on another
> thread), we figure out a "stop condition" for the SAX parser (you've got an
> element named 'foo', for instance), and then let the parsing thread run to
> that point, building up the fleshed-out object model as it goes.
>
> So the interesting part is that at any point, we can ask the parser
> framework to switch modes and give us the rest of the SAX stream raw,
> without building any more object model.  It just replaces the SAX handler
> proxy midstream with whatever handler we give it, and lets the events run
> out their course.  This way, an (axis) Handler for the body element can
> simply say "doc.getAsSAXStream(myHandler)".
>
> This seemed to be a pretty good compromise between the ease-of-use you get
> with JDOM and the ability to stream if you want it.  We would very much
> appreciate input on this, and I'm writing up a message to send to the JDOM
> development list to see what they think of the idea.
>
> --Glen
>
> ----- Original Message -----
> From: "Sam Ruby" <ru...@us.ibm.com>
> To: <ax...@xml.apache.org>
> Sent: Monday, March 05, 2001 8:42 AM
> Subject: Re: JDom
>
> > Steve Graham wrote:
> > >
> > > So the sequence would be:
> > >  ---> bytes on the wire
> > >    ---> pull-based SAX
> > >      ---> Java objects (maybe, but not always (eg intermediary))
> > >        ---> make the call (usually)
> > >         ---> Java objects
> > >           --->bytes on wire
> >

--
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)