【IT168技术分析评论】

XML 是关于灵活性的

　　不需要详细研究 XML 起源的长期历史原因，在开始这个讨论话题之前我想再次重申 XML 最初确实是关于灵活性的。XML 提供了一种供应商中立的格式来表示数据。根据对 XML 规范内容和要求的一致理解，应用程序可以轻易生成这种格式，并且其它应用程序也可以方便地使用这种格式。

　　以更通俗的语言来说，如果您告诉我您使用的是 XML，然后再告诉我您所使用的元素和属性，我很快就能写出能读取和使用 XML 的代码来。反过来也一样，如果我向您提供了我的约束模型 (constraint model)(通常为 DTD 或者 XML Schema 格式)，您就能够很快地操作我的数据。

　　最初的 API 可以维持这种灵活性

　　不足为奇，当 XML API 刚开始出现的时候，它们都非常的简单。最初版本的 Simple API for XML(SAX)和文档对象模型(Document Object Model，DOM)只具备非常基础的操作。您可以从某个元素中获得数据，操作其子元素，找出某个属性的值等，全部都是这方面的操作。除了处理 XML 的词汇结构之外，这些 API 并未提供大量的特性。

　　在 XML 发展的初期，这被认为是件好事。这非常像过去程序员对 C 语言和汇编语言做的一样，以对计算机中底层的比特和字节维持最大控制，SAX 特别适合于处理原始的 XML 文档 — 具有基本格式的数据 — 并允许您的程序完成需要的操作，而不需要花费业余时间研究这些 XML API。

　　然后出现了包装 API

　　首次告别低级控制 — 从理论上说实现了开发人员友好的 API — 的是 JAXP，Sun 公司用于处理 XML 的 Java API。最初，JAXP 的目标是从 SAX 和 DOM 代码中移除一些特定于供应商的信息(涉及到所使用的 XML 解析器)。

　　然而，为了努力提供一些便利，JAXP 提供了几个辅助方法(helper method)，从本质上说就是把 SAX 和 DOM 中已有的功能封装起来。因为 Sun 公司在 Java 市场上影响如此巨大，所以开发人员很快就开始使用这些辅助方法了，并且很少再直接操作 SAX 和 DOM 了 。

　　程序员仍然需要了解 SAX 的基本原理(如什么是 ContentHandler 以及如何实现回调方法)，但是 JAXP 抽象出了很多这样的细节。事实上，要执行特定的动作，如设置一些 SAX 中不常见的词汇句柄，我们不得不 绕开 JAXP 而直接操作 SAX。

　　如今又出现了数据绑定，JDOM 和大量的 API

　　差不多在十年之后(取决于您所使用的日期)，又出现了许多其它种类的 API。除了 SAX、DOM 和 JAXP 之外，我们还可以使用 JDOM、XOM、dom4j、StAX 和一些其它的变体非常直接地操作 XML。一些数据绑定 API，如 Zeus、Castor 和 JAXB 能允许我们在对 XML 没有多少了解的情况下处理 XML，而不用操作 XML 文档表示为逻辑数据而不是字符串或其他数据的数据。并且 Eclipse 之类的框架将完成所有这些操作，而您只需指定、单击和修改 XML 就可以了。从字面上看，有数百种方案可供选择(使用 XSLT 后我甚至不需关心 XML 的转换了)。

　　我们仍然具备灵活性吗?

　　掌握了所有可用于操作 XML 的 API 之后，Java 和 XML 程序员似乎具备了前所未有的高度灵活性;那么选择就意味着灵活性吗?我们稍微质疑一下这一断言，看它是否真的站得住脚。

　　解析程序中的灵活性

　　毫无疑问，我们能够使用所想要的任何 XML 解析器，任何版本和风格的解析器都可以，只要我们具有某些类文件 — 大多数情况下，这些文件都捆绑在所选的 API 中。因此要方便地从 XML4J 转换到 Sun 公司的老式 Crimson 解析器再到 Apache Xerces(版本 1 或版本 2)是非常简单的。JAXP 之类的 API 可以很轻松地实现这个过程(尽管我在侧栏中指出在所有新 API 出现之前这在 SAX 或 DOM 中就已经可用)，并且在很多数据绑定 API 中，我们甚至完全意识不到正在进行的解析;解析都隐藏在幕后。因此毫无疑问，我们可以马上使用任何想要的解析器。解析器中的灵活性被证实。