OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XML too hard for programmers?

[ Lists Home | Date Index | Thread Index ]

rog@vitanuova.com wrote:

>I'm afraid I'm new to this list, so am probably breaking 300 list

i am sure i am breaking some too so you are not alone :-)

>It's just a simple and small solution to an XML parsing problem I had,
>which was satisfactory at the time, seems to me to be generally
>applicable, and I haven't seen anything similar. Sorry in advance
>about the length.
i think so too and is on the reason i worked on XmlPull API 

>First thing: this is no panacea, and to be quite honest, I'm actually
>(heretic!)  not at all keen on XML, but this API at least made things
>bearable; the structure of the code dealing with the XML was quite
>logical, and the space used in doing so was largely bounded.
that is true about pull parsing: in general: the code that is doing 
parsing tends to mirror
XML structure and i even went so far as to say that it is pattern common 
in xml pull parsing

>I developed it when I was writing a browser for the Open Ebook
>standard to run on limited memory platforms.  Obviously DOM was out of
>the question, and SAX became really awkward as it would have been
>necessary to traverse the whole XML tree from the start when moving
>back a page; moreover I found it difficult to write code that
>corresponded directly to the DTDs.
>The idea is very simple: treat the XML as a multi-level stream, and
>provide an interface that allows one to *mark* a place in the stream,
>and *go to* a previously marked place.
that goes one step above and beyond streaming pull parsing however i was 
already experimenting with something like that in XPP2 XmlPullNode that 
allowed to build XML tree in memory on demand and even for sub-trees to 
access directly XPP2 event stream and i was very happy with capabilities 
of such "mixed" API.

>The basic API looked something like:

>Open()ing an XML file produces a parser p; then p.next() produces the
>next XML item in the file *at the same nesting level*.
that is main different when comparing  witrh XmlPull as next() in 
XmlPull returns move stream to next event doing depth-first iteration 
(exactly like SAX).

>	p := xml->open("foo.xml");
>	while ((i := p.next()) != nil)
>		process_item(i);
>will only process the top level elements.
this will process top level elements in XmlPull:

while( parser.nextTag() == pp.START_TAG ) {

>A crucial point is that when you get to the end of the current nesting
>level, next() returns nil; this allows one to easily write a
>recursive-descent-style parser, for instance (from the ebook reader)
>parses a <head> tag:
nextTag in XmlPull allows you to do the same as it returns only two 
vallues START_TAG or END_TAG and exception is thrown if input contained 
anything else

>	e_head(p: ref Parser, i: ref Item.Tag)
>	{
>		p.down();
>		while ((t0 := nexttag(p)) != nil) {
>			case t0.name {
>			"title" =>
>				e_title(p, t0);
>			"link" =>
>				e_link(p, t0);
>			"style" =>
>				e_style(p, t0);
>			}
>		}
>		p.up();
>	}
and here is how it could be done in XmlPull (for details see: 

	e_head(XmlPullParser parser) throws XmlPullException
		parser.require( pp.START_TAG, null, "item");
		while (parser.nextTag(parser) != XmlPullParser.START_TAG) {
			if( "title".equals(parser.getName()) {
			} else if( "title".equals(parser.getName()) {
			} else if( "style".equals(parser.getName()) {
			} else { // ignore uknonw elements 
		parser.require( pp.END_TAG, null, "item");

>Here, nexttag() is a locally defined function that returns the next
>Item that's a Tag, ignoring everything else.  The various e_*
>functions deal with the various kinds of tags that can be found within
>an XHTML <head> tag.
in XmlPull nextTag() is more restrictive and will skip only white space 
text content.

>This style of interface means that it's possible to write code that
>matches fairly closely the DTD, does not parse the whole document into
>one in-core data sstructure, and avoids having to write abstruse state
i agree completely :-)

>If the XML is in a seekable file, you can mark a place in the file
>(which records all the state of the XML parser at that point in the
>file, and a place to seek to), and then return to it later, or even
>store the mark externally and use it as an index for rapid
>retrieval at a later date.
>This means that for files containing a large dataset (e.g.  Ebooks!)
>you don't necessarily have to store all the dataset, even in a derived
>data structure.
if you want minimal memory overhead (and not just create DOM and 
navigate it)
you can record XML context of one position in file (that would include 
i-scope namespace
declarations, stack of start tags, attributes etc.) and use it to move 
back parser and
then restart parsiing from this position though  i have not seen parser 
that can do this ...

>I'm aware that my parsing of XML is probably hopelessly naive, and
>perhaps there is some facet of XML that makes this approach impossible
>for XML in general (I came up with this for a specific problem, after
>all).  If so, I'd love to know why.
thi sapproach means that parsing is done again and again each time you 
move back in stream (and this can only work with stream that supports 
efficient marking and going back - this works fine for files but is not 
case for networks sockets ...)

>If not, I hope I've managed to contribute a thought or two to the
it was very interesting post and showing that we have similar problems 
and come up with
similar approaches ot solve them.




News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS