SOA Specifications - XML - Why SAX is Good for DOM

Home	XML Specs	WS-* Specs	Other Specs

Learn About Self-Study Kits for SOA Certification Exams at SOASelfStudy.com

View the Schedule for the Public SOA Certification Workshops at SOAWorkshop.com

Visit the SOAPatterns.org Community Site and Learn About SOA Design Patterns

Read the SOA Manifesto and Become a Signatory

Why SAX is Good for DOM
by Thomas Erl

The traditional programming interface provided by the World Wide Web Consortium (W3C) for XML documents, has been the Document Object Model (DOM). One of the most common complaints about the DOM has been the requirement that the entire contents of an XML document be loaded into memory in order for the DOM to provide a complete tree view of the information. When dealing with larger data sets, this can cause serious performance challenges.

It is these challenges that XML developers were dealing with, which sparked the idea for the Simple API for XML. SAX evolved from an XML mailing list discussion into a full-blown specification, providing an alternative “light-weight” API for XML documents. The best way to compare the two APIs is to associate them with database cursors. DOM is more like a static recordset allowing updates, inserts and deletes, whereas SAX is more comparable to a directory-like, read-only cursor for efficient data access.

There is an amicable relationship between the two APIs, in that SAX can be used to create or read portions of a DOM tree. This flexibility has made SAX a valuable addition to the XML family of technologies, which is why many major XML vendors have added support for SAX to their products.

Originally, SAX APIs were designed for use by the Java programming language. Later, C++ and Visual Basic support was added. Quite simply, the API provides a programmatic interface like any other API, it just limits the amount of XML document data that is loaded into memory. It accomplishes this through an event-driven model that notifies the programmer of certain events prior to delivering the data. This approach is very efficient, and while it will not be suitable for all situations, it addresses many of the performance concerns of DOM.

Through a series of callbacks, the SAX’s event driven API notifies the application of the occurrence of key document elements, as the document structure is traversed in a linear fashion. For instance, the following simple document:

<?xml version="1.0"?> <book> <title>Playing the SAX</title> <author>Kenny Gee</author> </book>

…would produce the following series of events

1. start document
2. start element: book
3. start element: title
4. characters: Playing the SAX
5. end element: title
6. start element: author
7. characters: Kenny Gee
8. end element: author
9. end element: book
10. end document

The primary Visual Basic interface for SAX, as provided by the MSXML 3.0 parsing engine, is called IVBSAXContentHandler. This interface is implemented in order to gain access to the core information set within an XML document. Secondary interfaces, such as LexicalHandler, DTDHandler, and DeclHandler provide a model for the remaining XML document properties.

Since SAX supplies functionality not present in, but still compatible with DOM, it should not be considered a competing technology with the W3C’s Document Object Model, but rather a support API that will likely be commonly used alongside DOM.

SOA Design Patterns
by Thomas Erl

Foreword by Grady Booch

With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.

Web Service Contract Design & Versioning
for SOA
by Thomas Erl, Anish Karmarkar, Priscilla Walmsley, Hugo Haas, Umit Yalcinalp, Canyang Kevin Liu, David Orchard, Andre Tost, James Pasley

Foreword by David Chappell