事件驱动的文档解析
在SAX解析器装载XML文件时，它遍历文件文档并在其主机应用程序中产生事件（经由回调函数、指派函数或者任何可调用平台完成这一功能）表示这一过程。这样，编写SAX应用程序就如同采用最现代的工具箱编写GUI程序。

大多数SAX实现都会产生以下若干类型的事件：

在文档的开始和结束时触发文档处理事件。
在文档内每一XML元素接受解析的前后触发元素事件。任何元数据通常都由单独的事件交付。
在处理文档的DTD或Schema时产生DTD或Schema事件。
错误事件用来通知主机应用程序解析错误。
显而易见，在处理文档时你最关心的就是元素事件了。通常，SAX解析器会向你的主机应用程序提供包含元素信息的事件参数；在最低程度下也会提供元素的名字。具体取决于你的特定实现，可以定义不同类型的元素事件代表不同类型元素的处理。例如，注释元素（它可能包含主机应用程序的处理指令）就经常在接受处理时产生特殊的事件。

下面我们就举个比较基本的例子。假如你把程序清单A中的XML文件装入了SAX解析器，那么你可能会在你的主机应用程序中收到以下事件通知：
Document Start
Element Start "catalog"
Element Start "book"
Element Start "author"
Data "Adams, Lamont"
Element End "author"
Element Start "title"
Data "Lamont's First Book"
Element End "title"
Element End "book"
Element End "catalog"
Document End

SAX对DOM
在什么情况下采用这种或者那种API并没有确定的严格规则；具体情况具体分析。所有的SAX处理都在一次遍历中完成的；因此，在解析同等大小的文档时SAX通常会相比DOM提供更好的性能（因为DOM必须遍历树结构）。此外，与DOM是比，因为在给定的时间之内只需要XML文档的一部分装入内存，所以SAX 通常在处理更大文件时内存的利用效率也来得更高（我已经提到过，DOM在开始解析文档之前必须把全部XML文档装入内存）。

然而，SAX也不是没有缺点。SAX应用程序一般都比较长，程序中充斥着大量的if/else结构用来确定处理特定元素时所采用的运动。同样的，处理多个XML元素之间散布的数据结构也很成问题，因为解析事件之间必须保存中间数据。最后， SAX应用程序的事件处理结构一般意味着SAX应用程序是针对特定文件结构定制构建的，而DOM应用程序则更具一般性。

从哪里获得SAX
相当多的SAX实现都可以从网上获得。不幸的是，它们之间稍有不同，但其大多数都提供了相应的帮助文档。以下是一些流行的SAX实现：

当然，最“标准”的Java版本在SAX项目网站。
Microsoft XML Core Services 4.0 库包括了采用COM的SAX解析器，对VB程序员特别有用（或开发Windows的程序员）。
支持Perl的binding of SAX 2.0。
SAX in C++ 是一套用在SAX和C++应用程序中的C++接口和封装类。
许多编程语言，比如Python和所有的.NET语言都在其核心功能中内建支持SAX。