SAX2

Why Not to Choose SAX?

No API solves problems by itself, and SAX avoided the kitchen sink syndrome better than many others. So there are times it will be clear SAX isn’t the whole answer for some particular application-processing stage, even when you have the option to choose it. It will often still be the right way to get data into or out of another processing stage, particularly since many other APIs can interface with SAX. Also, building custom data import/export tools with SAX is fairly easy.

Probably the biggest single issue with SAX is that by itself it doesn’t provide random access to XML data. Its event stream is “forward-only”: you can’t go backwards or reorder it without your own record of the events. Such data structure policy would be handled by application layers on top of SAX, and you’ll need such layers if you use random access models such as XPath. Typically, applications use SAX to construct data structures that are either customized for their particular random access requirements or generic (typically DOM-like). You might create Person objects and index them by name, perhaps in some sort of hash table or using some kind of database as a backing store. In some applications it’s acceptable to just re-scan small to midsize XML documents on demand; it can be inexpensive when modern operating systems have already cached the data.

If you’re looking for an API that helps you write a low-level XML text editor and lets you work with malformed XML while it preserves ...