XML 问题: Ajax 权衡：XML 的多种风格

文档选项 将此页作为电子邮件发送 未显示需要 JavaScript 的文档选项

级别： 中级

Dethe Elza (delza@livingcode.org), 高级软件开发人员, Uniserve Communications Corporation
David Mertz, Ph.D (mertz@gnosis.cx), 作家, Gnosis Software, Inc.

2007 年 4 月 26 日

Ajax 代表 Asynchronous JavaScript and XML，其思想是：利用具有高可靠性的现代 Web 浏览器，可以在使用 Web 应用程序的同时，通过服务器连接来回传递数据。标准的 Web 技术会沿着链接前进，导致整个页面重新装载，而 Ajax 突破了这个限制。基于 Ajax 开发的许多方面需要不同于传统 Web 页面的设计决策：如何管理返回按钮、如何显示更新的数据、以什么频率发送更新等等。本文只关注其中一个问题：应该以什么格式交换数据？

选择很多。Ajax 中的 X 代表 XML，但是 XML 并非一种语言，它是一种用来构建语言的工具。所以，您要做的第一项决定是：是使用一种现有的语言，还是构建自己的语言？这要涉及几方面的权衡。必须考虑是否有一种现有的语言能够满足自己的需要，或者您是否能够设计一种更适合需要的语言？是否有处理这种语言的工具，还是必须自己构建工具？如果您要与别人交流（如果不需要与别人交流，那为什么要构建 Web 应用程序呢？），那么别人也熟悉这种语言吗？其他应用程序能顺利访问和使用您的数据吗？

可以从以下格式中进行选择：(X)HTML（包括微格式子集）、SVG 或 X3D（用于图形数据）、Atom（用于随时间变化的数据片段）、OPML（用于简单的大纲）和 RDF（用于语义性图表）。在极端情况下，可以发送 DocBook、DITA 或 OpenOffice 格式的数据，这些格式非常复杂、具有语义性而且功能全面。（关于这些格式的更多信息参见 参考资料。）

在另一个极端，可以不理会 XML，转而发送任何类型的数据。可以发送二进制数据、图像、电影或 PDF 文件；但这是一种倒退，这些数据很难在浏览器中用 JavaScript 进行操作。更易于为人接受的方法是，发送比 XML 简单的文本格式：由制表符或逗号分隔的列表、Markdown 或其他结构化程度较低的文本、YAML 或 JSON。即使不使用完整的 XML，您也有几十种选择，XML Alternatives 站点对这些技术做了全面介绍（参见 参考资料）。总之，选择的范围非常广，从最丰富也最复杂的，到没那么丰富更为简单的。而且，即使对于下面列表的一种格式，也可以找到多种数据编码方法，所以这个分类是有争议的，只能算是一种粗略的分类。

• OpenOffice Spreadsheet
• DITA（Darwin Information Typing Architecture）
• DocBook
• RDF-XML
• XHTML
• Microformat
• Atom
• OPML（Outline Processor Markup Language）
• Custom XML
• Markdown / Textile / reStructured Text
• YAML（YAML Ain't Markup Language）
• JSON（JavaScript Object Notation）
• 由逗号或制表符分隔的文本

应该衡量哪些因素？

面对如此之多的选择，如何做出合理的决定呢？出于如下几个原因，上面的列表无法严格地按照复杂性的次序排列。

• 首先，大多数格式都可以按照简单方式或复杂方式使用。
• 其次，必须区分复杂性表现在哪些方面：创建、读取、解析还是处理？XML 本身是相当复杂的，但是现有的工具比较成熟，例如浏览器中已经存在的解析器会使解析步骤简化。
• 第三，复杂性在很大程度上依赖于要处理的数据类型。数据是否具有非常严格的结构，比如电子表格或数据库？数据的结构是否非常松散，比如字处理文档或 blog 文章？数据是大文档（比如飞机的操作手册），还是小的数据片段（比如响应编码）？如果数据集非常大，那么是必须同时发送完整的数据集，还是可以根据需要发送它的片段？将大数据集分割为小片段是否很困难？为了在另一端将小片段正确地重新组装起来，必须添加多少额外信息？

那么，最关键的因素是什么？它们包括：

• 详细程度/带宽（不像您想象得那么重要，只是有时候很重要）
• 可读性（以及可写性和可维护性）
• 解析的简便性（客户端和服务器端）
• 解析的速度（本机还是通过脚本）
• 信息丢失（比如，有序对 -> 词典 -> 集）
• 灵活性（有时候，灵活性低反而更好，这样更容易预测会发生的情况）
• 语言可移植性（可以用多少种语言操作这种格式？）
• 正确性（是否能够轻松地检查和确保数据符合格式？）
• 往复转换（即 Markdown -> XHTML -> Markdown，在这个过程中会丢失多少数据？）

在大多数情况下，优化的目标并不是速度、带宽利用率或者其他效率指标，而是更模糊的目标：用户满意度。即使有轻微的网络延迟，如果能够将延迟掩盖起来，让更新显得 很及时，那么这点延迟就不是问题了。毕竟，让用户更满意就是 Ajax 比生成完整的新 Web 页面更先进的原因。