当你需要处理XML文档时，你的首要选择是使用DOM(文档对象模型)还是使用SAX(用于XML的简单API)，即当前使用的两个主要的XML
API。你可以使用任何一种(或者在同一时间使用两种)来处理XML文档，然而DOM将文档载入到内存中处理，而SAX则相反，它可以检测一个即将到来的
XML流，由此并不需要所有的XML代码同时载入到内存中。
选择DOM与SAX，与在一个数据库中的表单与视图之前选择一样：选择适合于当前实际情况的方法。如果你只是想简单地查看XML文档而不处理它，那么请选择使用SAX。
SAX与DOM之间有一些显著区别，包括：
DOM是复杂对象处理的首选，比如当XML比较复杂的时候，或者当你需要随机处理文档中数据的时候。SAX从文档的开始通过每一节点移动，以定位一个特定的节点。
DOM
为载入到内存的文档节点建立类型描述。最终，这些描述呈现了可容易横向移动、潜在巨大、树型结构。如果XML很冗长，DOM就会显示出无法控制的胀大。例
如，一个300KB的XML文档可以导致RAM或者虚拟内存中的3，000，000KB的DOM树型结构。通过比较就会发现，一个SAX文档根本就没有被
解构，它也没有隐藏在内存空间中(当然当XML流被读入时，会有部分文档暂时隐藏在内存中)。SAX就是一种“更轻巧的”技术──它可以给你的系统带来更
轻的负担。SAX相当于观看一场马拉松比赛，而DOM就好比邀请所有的比赛选手到家里参加晚餐。
所以，你如何选择SAX和DOM？如果你处理复杂的东西，比如高级XSLT转换，或者Xpath过滤，请选择使用DOM。如果你建立或者更改XML文档，你也可以选择DOM。
相反，你可以使用SAX来查询或者阅读XML文档。SAX可以快速扫描一个大型的XML文档，当它找到查询标准时就会立即停止，然后再处理之。
在某些情况下，在一个方案中，最佳的选择是使用DOM和SAX处理不同的部分。例如，你可以使用DOM将XML载入到内存并改变它，然后通过从DOM树中发送一个SAX流而转移最后的结果。
SAX概念
SAX是Simple API for XML的缩写，它并不是由W3C官方所提出的标准，可以说是“民间”的事实标准。实际上，它是一种社区性质的讨论产物。虽然如此，在XML中对SAX的应用丝毫不比DOM少，几乎所有的XML解析器都会支持它。
与DOM比较而言，SAX是一种轻量型的方法。我们知道，在处理DOM的时候，我们需要读入整个的XML文档，然后在内存中创建DOM树，生成
DOM树上的每个Node对象。当文档比较小的时候，这不会造成什么问题，但是一旦文档大起来，处理DOM就会变得相当费时费力。特别是其对于内存的需
求，也将是成倍的增长，以至于在某些应用中使用DOM是一件很不划算的事（比如在applet中）。这时候，一个较好的替代解决方法就是SAX。
SAX在概念上与DOM完全不同。首先，不同于DOM的文档驱动，它是事件驱动的，也就是说，它并不需要读入整个文档，而文档的读入过程也就
是SAX的解析过程。所谓事件驱动，是指一种基于回调（callback）机制的程序运行方法。（如果你对Java新的代理事件模型比较清楚的话，就会很
容易理解这种机制了）
在XMLReader接受XML文档，在读入XML文档的过程中就进行解析，也就是说读入文档的过程和解析的过程是同时进行的，这和DOM区
别很大。解析开始之前，需要向XMLReader注册一个ContentHandler，也就是相当于一个事件监听器，在ContentHandler中
定义了很多方法，比如startDocument()，它定制了当在解析过程中，遇到文档开始时应该处理的事情。当XMLReader读到合适的内容，就
会抛出相应的事件，并把这个事件的处理权代理给ContentHandler，调用其相应的方法进行响应