即便对高级 XML 问题具有丰富经验的开发人员也不一定就完全了解 XML 最基本的一些问题。为了为您打下坚实的基础，本文讨论了最基本的 XML 服务：解析。本文介绍了各种解析方法，着重说明了各自的优缺点。
了解基础
从 XML 的出现至今大约有 9 年的时间了。对于可扩展标记语言来说这是一段不短的历程。现在很难找到完全不用 XML 的应用程序了。
但是和客户在一起的时候，仍然不可避免地发现基础性的东西尚未被透彻地全部理解。对复杂的 XML 主题理解透彻的开发人员，最近却发现对基础性的东西(比如解析)的把握还存在很多不足，这真有点出人意料。
而对 XML 的处理是从何处开始的呢?没错，是解析。解析可能是开发人员能够使用的最基本的服务。解析器读取 XML 文档，解释语法并向应用程序传递有意义的对象。解析器可能还提供其他服务，比如验证(保证文档符合 XML Schema 或 DTD)或者名称空间解析。
本文介绍了各种解析方法，着重分析了各自的优缺点，帮助您在下一个项目中选择适当的工具。文中包含大量文章的链接，选择工具的时候可以详细研究给定的 API。
解析的重要性
解析为什么重要?因为所有 XML 处理都从解析开始。无论使用高层编程语言(如 XSLT)还是低层 Java 编程，第一步都是要读入 XML 文件，解码结构和检索信息等等，这就是解析。
解析文档时面临的第一个选择是采用现成的解析库(基本上每种编程语言都有，包括 COBOL [Common Business Oriented Language])还是自己创建一个。答案非常简单：选择现成的库。
坦白地说，XML 不是一种多么复杂的语法，因此认为可以自己通过正则表达式或其他特殊方法来解析的想法是可以理解的。但实际上却很难成功：XML 语法要求支持多种编码和很多难以捉摸的特性，比如 CDATA 节和实体。自定义的实现几乎很难照顾到所有这些方面，因而造成了不兼容性。
相反，随开发环境提供的解析器大都经过了与兼容性有关的测试。采用 XML 这样的标准语法的主要原因是兼容其他应用程序和工具箱，这是真正值得使用经过良好测试的库的情况之一。
多数解析器提供了至少两种 API，通常是一个对象模型 API 和一个事件 API(也称为流 API)。比如，Java 平台同时提供了 DOM(文档对象模型)和 SAX(Simple API for XML)。
这两套 API 提供了相同的服务：文档解码、可选的验证、名称空间解析等等。差别不在于服务而在于 API 使用的数据模型。
关键的选择：第一种方法
对象模型 API 定义了层次化对象模型来表示 XML 文档。换句话说，对应 XML 语法中的每个概念定义相应的类：元素、属性、实体、文档。解析器读入 XML 文档的时候，建立 XML 语法和类之间的一对一映射。比如，每遇到一个标记，就实例化一个元素类。
毫不奇怪，对哪种数据模型最好存在一些争议。W3C 规范化了 DOM，它的主要优点是可移植性：它是作为一种 CORBA 接口定义的，被映射到很多语言。因此如果了解了 JavaScript 中的 DOM，也就知道了 Java、C++、Perl、Python 和其他语言中的 DOM。
另一种数据模型是 JDOM，一种针对 Java 优化的 DOM(专用于 Java)，和 Java 语言结合得更紧密，但是按照定义缺乏可移植性。
尽管人们可以继续商讨对 XML 语法来说哪种数据模型最好，但我认为没有多少意义，因为各种基于对象的 API 其优点和不足基本上是一样的。从好的方面来说，如果熟悉 XML 语法的话，对象模型 API 更容易理解。因为它直接从 XML 语法映射到类，很容易学习、使用和调试。
简单的代价是效率，至少对很多项目而言是这样。读入文档的时候，解析器根据语法结构创建对象。对很多应用程序来说，XML 语法并不是很合适：
XML 语法非常罗嗦，即使文档很小，解析器也要创建很多对象。
对 XML 词汇表进行的优化通常针对的是存储和数据传输效率，而不是处理，因而应用程序可能需要对数据进行预处理，比方说，在开始真正的处理之前，先计算部分和或者合并其他来源的数据。很多情况下，在处理之前必须将数据从 XML 对象模型复制到应用程序专用的对象模型或者数据库。
因为这种对象模型是通用的，包含很多应用程序并不需要的对象之间的引用(比如，从子元素到父元素的反向引用)。这些引用进一步增加了内存消耗。
在桌面上处理小型文档这可能不是大问题，但是在其他环境中，比如服务器上，对象模型固有的低效率是不可接受的。