Other tasks, such as sorting, rearranging sections, getting from a link to its target, looking up information on one element to help process a later one and the like require accessing the document structure in complex orders and will be much faster with DOM than with multiple SAX passes.
Some implementations do not neatly fit either category: a DOM approach can keep its persistent data on disk, cleverly organized for speed (editors such as SoftQuad Author/Editor and large-document browser/indexers such as DynaText do this); while a SAX approach can cleverly cache information for later use (any validating SAX parser keeps more information than described above).
Processing XML documents larger than main memory is sometimes thought impossible because some DOM parsers do not allow it.
Virtually any kind of XML validation requires access to the document in full.
Additionally, some kinds of XML processing simply require having access to the entire document.
XSLT and XPath, for example, need to be able to access any node at any time in the parsed XML tree.
[1] The user defines a number of callback methods that will be called when events occur during parsing.
Properly speaking, the SAX interface does not deal in elements, but in events that largely correspond to tags.