级别： 初级 Uche Ogbuji (uche@ogbuji.net), 首席顾问, Fourthought Inc.
2006 年 5 月 25 日 Thinking XML 专栏的作者 Uche Ogbuji 继续讨论 XML 最佳实践这个主题。上一期文章 “创建 XML 的好建议” 中介绍了专家关于 XML 设计的建议。本文将介绍来自 Internet 工程任务组（IETF）的建议，该组织的技术论文促成了大多数 Internet 协议的开发。IETF 的 XML 建议都集中在 RFC 3470 “Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols” 中。
Thinking XML 专栏的上一期文章 “创建 XML 的好建议” 讨论了专家为 XML 开发人员所提出的两方面的建议。设计的 XML 主要用于 Internet（更确切地说是 Web），很多 Internet 协议使用 XML 表示数据和文档。因此对于所有开发 Internet 技术的主要标准组织 XML 都很重要，其中包括 Internet 工程任务组（IETF），IETF 的技术论文形成了大多数 Internet 协议，从电子邮件到 Web 通信，等等。为了保证在 IETF 技术中使用的 XML 具有一定的质量，IETF 开发了一套设计指南，编纂形成 RFC 3470，标题为 “Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols”（请参阅 参考资料）。本文将讨论并详细阐述 RFC 3470 所提供的这些很有价值的建议。
背景和基础
文章的大部分介绍关于 XML 的背景知识。但是正如 1.1 节中所指出的那样，“有经验的 XML 实践者可能已经熟悉这些背景材料，但是后面的建议也适合于这类读者。”自然，我将直接进入提供指导意见的那些章节。
第 2 节 “XML Selection Considerations” 描述了决定是否在 IETF 技术中使用 XML 时开发人员应该知道的因素。但我认为这一节的内容对于 XML 在其他很多环境中的使用也同样有价值。第 3 节讨论了可用的 XML 替代技术，特别是 IETF 协议中使用的那些，如 Abstract Syntax Notation 1 (ASN.1) 和 External Data Representation (XDR)。有关完整的 XML 替代技术列表，请访问 Paul Tchistopolskii 的网站（参见 参考资料）。
4.3 节讨论可能需要为 XML 增加的语义限制。比如，一条规则说 “所有结构良好的 XML 只要不使用 CDATA 节都是可接受的”。这类额外的限制一直存在争议。最知名的例子可能是 SOAP。它不允许处理指令、文档类型声明和任何内部 DTD 子集。RFC 3470 不鼓励采用这些限制，我非常赞同。这些限制降低了互操作性，从而违背了 XML 的一个核心目标。RFC 承认有些情况下由于切实的原因不得不限制语法的变化。XML 文档的数字签名就是一个很好的例子。对于这种情况，RFC 非常明智地建议限制为 Canonical XML，即专门为此量身定制的一种 W3C 规范（参见 参考资料）。其中的意思是，要么允许使用所有 XML 特性，要么强制使用 Canonical XML。不要发明您自己的一类受限 XML。
4.4 节讲述 XML 声明。我认为这一节的建议比较软弱，没有必要拘泥。我以前的 developerWorks 文章（参见 参考资料）中曾经指出，强烈建议使用指定字符编码的 XML 声明，除非有很好的理由不这样做。即使采用默认 UTF-8 和 UTF-16 编码的文档也应该有这样的声明。RFC 3470 中给出了不这样做的一个理由。如果 XML 作为片段内嵌在更大的格式框架中，可能没有理由要求每种情况下都带有声明。
表示内容
RFC 在 4.5 和 4.6 节讨论内容结构，就何时使用处理指令和注释提供了非常合理的建议。4.7 节非常有趣。我认为这一节根本没有提出任何真正可靠的原则。但这并不是缺点，它清楚地反映了 XML 专家在使用何种模式语言、什么样的可扩展性和模式演化技术最佳这些问题上的矛盾状态。不幸的是，这一节并没有真正涵盖这些问题的广度或者提供参考资料。
4.13 节讨论了一般内部和外部可解析实体，倾向于不鼓励使用这类实体。RFC 中指出：
该特性增加了 XML 处理的复杂性，似乎更适合于在文档处理而不是数据表示中使用 XML。因此，本文建议避免在协议规范中使用实体声明。
这似乎隐含着这样的意思，即 IETF 技术报告不关心文档处理，但我认为这是一种奇怪的观点，而且和 4.3 节关于限制 XML 语法的讨论冲突。一个很好的反例是 Atom，这是 RFC 4287 中定义的一种 Web 信息提要交换格式。Atom 当然是一种文档格式，而实体显然适合在 Atom 文档中使用。我建议，读者应该比 RFC 3470 4.13 节的建议更慎重一点，逐个分析一般可解析实体在基于 XML 的规范中的适用性。4.14 节几乎是顺便提到，消息传递协议中使用外部实体会造成消息不是自含的这种情况。这当然是协议作者要解决的一个问题。正是因为这种复杂性，所以才不要求 XML 处理程序解析外部实体引用，因此使用外部实体会造成互操作性问题。比如，Mozilla® 应用程序包（以及诸如 Firefox® Web 浏览器之类的派生应用程序）这种应用广泛的 XML 处理程序就不去管外部实体引用，而是在处理中悄悄地丢掉这类引用。
4.16 节讨论了一个令人迷惑的领域，即 XML 空白处理。不幸的是，它的下列断言更增加了这种迷惑性：
XML 实例中所有空白都被认为是重要的，默认对处理程序是可见的。
的确，一种常见的错误是假定可以忽略 XML 中的任何空白（可能是从 HTML 处理中继承来的习惯）。就像这句话所说的那样，默认情况下空白是重要的，但并非所有空白都是重要的。假设使用 DTD 并且声明了某个元素，实例中该元素的一个子节点仅由与 PCDATA 声明不匹配的空白组成。该节点就会被认为是可忽略的或者不重要的空白，解析器可能用一种特殊的方式报告它。比如，常见的 SAX API 允许解析器使用 ignorableWhitespace 事件而非
characters 来报告这类文本，后者用于字符数据。我认为必须明确这种区别，否则用户可能会对能够识别可忽略空白的解析器的行为感到不解。
结束语
虽然有少量不当之处，但我认为 RFC 3470 仍然不失为一份很好的文件。就像我在本文中尝试说明的那样，该 RFC 的不同部分适合于不同的读者，但是我建议任何准备采用 XML 的人都应该读读下面这些章节：
- 第 2 章，“XML Selection Considerations”。即使 XML 高手也应该能够明确地说明什么时候应该使用 XML，什么时候应该避免使用。
- 4.3 节，“Syntactic Restrictions”。了解每种明智建议背后的理由，避免对 XML 任意施加词法限制。设计一种格式时要么强制使用 Canonical XML，要么允许各种底层语法。
- 第 7 章，“Security Considerations”。Internet 一直是安全担忧的因素，而 IETF 非常关注安全问题，包括关于 XML 处理的这种高层讨论。当然这一节讨论的并不充分。比如没有讨论 XPath 注入攻击的危险性。
如果您有关于最佳实践的建议或者有自己的想法，请在 Thinking XML 讨论论坛 上与他人分享。
参考资料 学习
获得产品和技术
-
用 IBM 试用软件 开发您的下一个项目，这些软件可直接从 developerWorks 下载。
讨论
关于作者  | 
| | Uche Ogbuji 是 Fourthought Inc. 的顾问和缔造者之一，这是一家专门从事企业知识管理 XML 解决方案的软件供应商和咨询公司。Fourthought 开发了4Suite，这是一个 XML、RDF 和知识管理应用程序的开放源码平台。Ogbuji 先生还是 Versa RDF 查询语言的主要开发人员。他是一位出生在尼日利亚的计算机工程师和作家，目前在美国卡罗拉多州博耳得定居和工作。您可以通过他的 Weblog Copia 进一步了解 Ogbuji 先生，或者通过 uche@ogbuji.net与他联系。 |
对本文的评价
| 
