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:
<title>Playing the SAX</title>
...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.
- Inside XML Schemas
- SOAP in a Nutshell
- Transforming Data with XSLT
- Understanding DTDs
- Why SAX is Good for DOM
- What You Should Know about XPath
- An XHTML Primer
- XLink - Inside and Out
- Data Access with XQuery
- XSL versus CSS
- Another Introduction to XML
- Unifying Corporate Data & Documents
- Replacing HTML Documents with XML
- Meta-Enable Your Enterprise
- The XML Data Custodian
- Integrating XML into the Enterprise
- The Wireless Enterprise
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.
Governing Shared Services On-Premise & in the Cloud by Stephen Bennett, Thomas Erl, Clive Gee, Anne Thomas Manes, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable
For more information about these books, visit: www.servicetechbooks.com