Network Computingwww.networkcomputing.com

Now let's discuss the three XML parser models in more depth.

Push Parsers

Push parsers are the class of XML parsers that publish a set of interfaces, implemented by applications, through which the parser relays document information.

SAX is the most well known XML push parser. After your application tells the SAX parser to begin parsing, the parser calls back (or pushes) into the application code to notify the application of parse events. This model forces application code to maintain state within the callback class(es), and to evaluate that state at each event. That means many class variables in the callback class(es), as well as (possibly) getters and setters for those variables. This isn't very developer-friendly as it creates a lot of extra work.

Additionally, SAX and most push parsers parse an entire document at once. As soon as your code tells SAX to begin parsing a document, the document is parsed in its entirety. For very large documents, this means lots of state information must be maintained – causing a potentially large memory footprint, not to mention all the wasted processing and battery power that goes into parsing an entire document if not all of it is needed (though not nearly as much as a DOM parser would require).

We'll examine push parser issues in more detail in the NanoXML section (page 583).

Object Model Parsers

Object model parsers are that class of XML parsers that build in-memory representations of XML documents using tree-like data structures. The most popular are parsers conforming to DOM Level 1 and Level 2 specifications, but others exist (for example, NanoXML).

Object model parsers, unlike push parsers, don't usually require the developer to maintain document state during parsing, but they have their own drawbacks on lightweight clients. Most lightweight object model XML parsers keep an entire parsed document in memory all the time, until the parser and its resources are garbage collected. Parsing a large document with this kind of parser, even if only one node from the whole document is required, always means occupying large chunks of memory. This approach isn't desirable on lightweight clients since their memory is constrained.

Also, as with push parsers, all the object model parsers for lightweights that I know about parse an entire document at once. As soon as your code tells the parser to begin parsing, the entire document is parsed so an in-memory object model can be built. As with push parsers, this wastes a lot of processor and battery power if the entire document is not required.

Lazy Parsing

Some heavyweight object model parsers offer lazy parsing, for example Xerces-J. Parsing lazily means that the object model is built and stored in memory only as the calling application requests a node. However, usually the entire ancestor-or-self axis (with respect to the requested node) is stored in memory after the request. Certainly, the entire ancestor-or-self axis must be parsed when a node is requested. This isn't optimal for constrained devices, but it's better than the "parse-and-store-it-all-at-once" approach taken by present-day lightweight object model XML parsers.

At the time of writing, no object model XML parsers are available for lightweights that use lazy parsing. Hopefully, this will change in the near future.

Pull Parsers

A newer player in the world of XML parsing, pull parsers aren't nearly as prevalent as SAX and DOM parsers. kXML and XPP appear to be the only feasible contenders today.

Pull parsers are particularly useful for lightweight clients because they parse only the minimal chunk of a document necessary when an application requests the next piece of data. The application can process this data at its leisure and then ask for the next piece, spurring the parser to parse just another small chunk of the document. This is similar to the workings of a java.io.Reader.

The benefits of this approach are:

• Processing and battery power are used when and only when the application needs the next piece of data; the application maintains control over its parsing needs

• Memory footprint is reduced; the parser only needs to maintain minimal state information and a pointer to the current element (although the document itself must remain in memory for as long as parsing might continue, so it's to the application's advantage to acquire what it needs quickly). An entire object model does not remain memory-resident.

Unfortunately, there is no standard interface yet for XML pull parsing, like SAX for XML push parsing or DOM for XML object model parsing. Therefore, although pull parsers sound great for lightweight clients, they may be too immature for use today in production applications. Applications would be stuck with the limitations of the parser selected by the development team without a clear upgrade path. It may be difficult or impossible (without rewriting the application) to change parsers in the future.