Re: Ganymede XML Pull Parser

Jonathan Abbey wrote:

> Hi, folks.  I just became aware of XMLPULL through O'Reilly's XML.com site.
>
> I implemented an XML Pull Parser on top of SAX in Java a couple of
> years ago that appears to have many similarities to XMLPULL.  I do use
> an XMLItem base class which I subclass for things like XMLCharData,
> XMLElement, XMLError, XMLStartDocument, and so forth, rather than
> having a single item type with a get_type() method, but it is
> otherwise very similar.

hi,

i thought i knew about all XML pull and pull-over-push parsers
- but i guess one can never know what is happening out there :-)

> Javadocs for my implementation can be found at
>
> http://tools.arlut.utexas.edu/gash2/doc/javadoc/arlut/csd/Util/XMLReader.html
>
> if anyone is interested in looking at it.
>
> The API is broadly similar to XMLPULL, except that I return discrete
> XMLItem objects, and provide a peek() method on the parser to support
> non-consumptive examination, rather than providing all accessor
> methods on the parser.

this is very similar to what is done in kXML1 API http://kxml.enhydra.org/

>  This is useful in that I can use my XMLItem
> class and its subclasses to at any point extract a tree of descendents
> if necessary, rather than sticking with a pure node-by-node parse
> pull.

when i have finished porting XmlNode from XPP2 to XmlPull API
you will have the same capability to encapsulate parser state
into node tree at any given moment, see XmlPullParserFactory.newNode()
in XPP2 (XPP2 is not implementing XmlPull API only XPP3 is
XmlPull API compatible - i work now on porting XmlNode/XmlPullNode
to XmlPull API):

  http://www.extreme.indiana.edu/xgws/xsoap/xpp/download/PullParser2/doc/api/

> In this way, I have the advantage of retrieving a DOM-like
> subtree at any time if that is most convenient for my code, without
> having to pay a full DOM price for the full document.

that is similar to use of XmlNode in XPP2 that allows
to construct xml node tree for any XML input subtree.

however with XmlPullNode i have gone one step further to
better hide that node tree is incrementally pulled from XML.
if you create XmlPullNode for top level element then you can
use it just like XmlNode (XmlPullNode _is_ XmlNode)
so it is as convenient as using DOM but if you need to read
only part of XML input for example when evaluating XPath query
only required parts of node tree are created - this has nice
implications about performance when streaming XML to node tree or
doing document classifications or routing like in SOAP see:

  http://www-106.ibm.com/developerworks/xml/library/x-injava/index.html

moreover XmlPullNode provides ability to get underlying pull parser
and to read parts of XML input directly without creating xml node tree.


http://www.extreme.indiana.edu/xgws/xsoap/xpp/download/PullParser2/doc/api/org/gjt/xpp/XmlPullNode.html

> In addition, I have a couple of minor convenience niceties which I'll
> mention only for personal pride, you have obviously encountered and
> made conscious choices about the same matters.

:-)

> The first is that the Ganymede XMLReader will eat adjacent open and
> close tags to provide a single element whose isEmpty() method will
> return true.  I see that you provide a similar method, though I
> believe code using XMLPULL will still need to eat the succeeding close
> tag?

if we had more event/object oriented API in XmlPull then there would
be no need for END_TAG for empty elements (in kXML1 i think
it is called getDegenerated() on StartTag event).

new Xml/Pull/Node will provide similar capability to build on top
of XmlPull API a tree oriented API that is much more efficient than
DOM when doing streaming parsing.

BTW: this is main design objective of XmlPull API. if you look on
kXML1 -> kXML2 and XPP1 -> XPP2 -> XPP3 you will notice
that APIs are becoming much simpler and lower level. intention
is that XmlPull API allows to create very fast (or very small for J2ME
with  low memory overhead) parsers that can be used to implement
higher level APIs.

> The second is that the Ganymede XMLReader can be configured to
> silently consume, rather than report, any all-whitespace text blocks
> between elements.

this was possible too in XPP1 and XPP2 to inform tokenizer that
input has no mixed content so tokenizer automatically removed
ignorable wheite spaces or reported error if element had mixed content
(useful when parsing SOAP message), see setAllowedMixedContent in

http://www.extreme.indiana.edu/xgws/xsoap/xpp/download/PullParser2/src/java/impl/pullparser/org/gjt/xpp/impl/tokenizer/TokenizerBufferOverflowException.java

however it is not that convenient when XML input has
parts that can have whitespaces ignored and other parts not
as you need to keep switching setAllowedMixedContent() ...

instead in XmlPull API we reached more convenient solution
that build on great strength of xml pull parsing: it is easy to combine
pull operations so we provide nextTag() (and nextText()) that
combined generic iterator next() to do useful skipping of ignorable
whitespaces before tags (and nextText() to treat in the same way
<a></a> and <a>...</a>), see:

  http://www.xmlpull.org/v1/doc/api/org/xmlpull/v1/XmlPullParser.html#nextTag()
  http://www.xmlpull.org/v1/doc/api/org/xmlpull/v1/XmlPullParser.html#nextText()


> Finally, the Ganymede XMLReader's implementation is sort of nice, as
> it is a threading adaptor between SAX and the XMLReader API.. there is
> a circular buffer of fixed size in the XMLReader, and a background
> thread which runs the SAX parser and accepts SAX events into the
> XMLReader.  If the event consumer runs ahead of the SAX parser thread,
> the peekNextItem() and getNextItem() methods on XMLReader will block,
> and if the SAX parser runs ahead of the XMLItem consumer thread, the
> SAX parser will block.

did you see XMLpull wrapper for SAX project at http://www.trantor.de/xml/ ?

it is doing exactly what you described (i think it was well discussed on xml-dev
but i never heard about your project ...)

> I wonder if you are doing something similar?

we have "native" XML pull parsing implemented without need
to use extra thread (and extra threads are not allowed in J2EE environments...)


> Anyway.  I'm quite happy to see others pushing forward with pull
> parsers.. it seems crazy to have to use either a low-level SAX type
> interface for anything significant, and it seems crazy to have to pay
> a full DOM price for large documents.

i think more choices allows developers to have tools that can be
well customized to their needs and ultimately to build better applications.

> Best of luck with XMLPULL.

thanks! we hope that developers wil find it both useful and easy to use.

alek

ps. your bugzilla seems to be moved or crashed: http://tools.arlut.utexas.edu/gash2/bugzilla/

Object not found!

     The requested URL was not found on this server. The link on the referring page seems to be wrong
or outdated. Please inform the author of that page about the error.

     If you think this is a server error, please contact the webmaster.

Error 404

tools.arlut.utexas.edu
     Wed Oct 23 00:29:13 2002
     Apache/2.0.43 (Unix) PHP/4.2.3 mod_ssl/2.0.43 OpenSSL/0.9.6g






------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/2U_rlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/