ThinkingXML:创立XML的好建议

XML 的应用越来越广泛，但是很多 XML 的结构并不好。即便结构良好，也经常设计得很糟，使得处理和保护非常艰苦。而大部分用于 XML 的基础结构使标题更加恶化。于是呈现了关于 XML 最佳实践的公然讨论，比如 Henri Sivonen 的文章“HOWTO Avoid Being Called a Bozo When Producing XML”。Uche Ogbuji 经常在 IBM developerWorks 上讨论 XML 最佳实践，这里他提出了在这些文章中讨论的要点。

几年来我一直在本专栏和其他系列文章中讨论 XML 最佳实践。其他人，比如和我同行的专栏作家 Elliotte Rusty Harold 也谈到这个标题。参加 XML 设计原则讨论的 XML 专家越好越好，这样社区就会对在不同层次上采用 XML 的开发职员供给一致的建议。本文将联合最新和过往的文章，更具体地先容了 XML 最佳实践。

不再有笨蛋

Henri Sivonen 撰写了一篇有用的文章“HOWTO Avoid Being Called a Bozo When Producing XML”（请参阅参考材料）。他采用了基于 XML 的 Web 提要格局（如 RSS 和 Atom）的观点，提出了用名称空间天生结构良好的 XML 应当做和不应当做哪些事情的指南。正如他在简介中所说的：

有些开发职员似乎认为以编程方法天生 XML 而保持结构良好非常艰苦（假如不是不可能的话），另一些开发职员却能够做到这一点，并希奇其他人为什么如此无能。我假设没有人愿意显得无能或者被点名。因此，我盼看下列建议能够帮助开发职员从第一类人转变成第二类人。

Henri 给出的第一条建议是“不要将 XML 看作是文本格局”，我认为这是一条危险的建议。当然其基础观点是准确的 —— 不能像简略的文本文档那样为所欲为的天生和编纂 XML，但是这种请求实用于所有有结构的文本格局。但是，说 XML 不是文本就背弃了 XML 一个最重要的特点，而这点在规范的 XML 定义中被奉为圭臬。（“文本对象是结构良好的 XML 文档[假如符合本规范]”。） Henri 的提法也让人糊涂，由于有关于 XML 文本的技巧定义，大致上是将它说明为 XML 的字符序列。文本不仅仅是叶子元素或者属性中的重要成分 —— 技巧上称这类文本为字符数据。文本还是所有 XML 实体的重要成分，因此说 XML 不是文本是自相抵触的。我认为夸张 XML 和开发职员已经熟悉的文本格局的差别会更有意义。

上面的评述表明，Henri 的建议可能由于过火关心天生结构良好的 Web 提要的标题而有些偏激。警告人们简略的堆砌字符串，期看它成为结构良好的 XML 的做法是危险的，这一点上他是准确的。我也在文章中建议人们应用成熟的 XML 工具箱而不是应用简略的文本工具来创立 XML（请参阅参考材料）。我疑虑的是 Henri 描写这个建议的方法有点混乱，在更广泛的 XML 处理高低文中会造成曲解。他在“Don't use text-based templates”和“Don't print”两节中重复重申这个观点。我认为可以将他的建议回纳为“不要应用不能保证产生结构良好的 XML 的机制。”这确实是一项很重要的建议。正像 Herni 所提到的，安全创立 XML 的一种方法是发送 SAX 事件，“应用树或栈（或者 XML 解析器）”。但即使这样做也不能令您高枕无忧。应用的 SAX 工具不必定要进行所有必要的结构良好性检查。比如，XML 中禁止某些 Unicode 字符。为懂得决这些标题可能需要进行额外的检查。

Henri 建议用户不要尝试手工治理名称空间，这是准确的。我曾经在 developerWorks 上讨论过，必需非常警惕地处理 XML 名称空间。他建议开发职员，按照同一名[名称空间同一资源标识符（URI）加上本地名]来考虑一般情况就行了，但有时候不可避免地要面对前缀或者 XML 声明。在 XSLT 这样的规范中，QName（前缀/本地名组合）可在属性值中应用，并假定前缀根据作用范畴内的名称空间声明说明。这种模式称为高低文中的 QName。在这种情况下，开发职员必需把持声明的前缀，否则 XML 处理就会失败。假如开发职员治理自己的名称空间声明，由于 XML 名称空间的复杂性，成果往往会显得混乱无章。

由于经过 XML 处理管道之后名称空间语法可能变得非常混乱，一种解决方法是在管道的最后插进一个规范化步骤。XML 规范化打消了 XML 1.0 和 XML 名称空间答应的各种语法变体，包含不同的名称空间声明方法。规范化不能打消使名称空间声明对开发职员变得危险的所有标题。规范化也不能解决高低文中的 QName 标题，由于它并没有转变文档中应用的前缀，但它确实可以减轻名称空间声明的混乱程度，使您很轻易断定标题所在，甚至可以编写代码主动改正这些标题。GenX 库是 Henri 建议应用的 XML 创立工具之一，能够主动天生规范的 XML，其他很多工具箱也作为选项供给了规范化功效。

Henri 关于 Unicode 和字符处理的建议基础上是完整准确的。不过我认为“Avoid adding pretty-printing white space in character data”一节有点夸张其词。多数情况下，元素之间而不是带有字符数据的元素内部的精致打印是安全的。如 Henri 所述，清单 1 所示的假如以清单 2 的情势浮现通常是不安全的。

清单 1. XML 例子

bar

清单 2. 在字符数据中增加空缺后的 XML 例子

　bar

但通常以清单 3 的情势打印 XML 是安全的，输出成果如清单 4 所示。

清单 3. 另一个 XML 例子

bar

　bar

很多 XML 序列化工具能够懂得相对安全和不安全的的打印格局。必需知道的是，假如在混杂内容中增加空格，则清单 3 和 4 中所示的精致打印情势可能造成扭曲。假如应用模式制导的序列化，则可以避免这类标题。但在实践中，应用混杂内容的多数词汇表对空缺规范化没有这么敏感，因此不用过于担心精致打印。应当充分懂得该标题，并知道没有措施封闭精致打印（最好默认不用精致打印）。Henri 提出了清单 5 所示的精致打印实践，但是我不批准，由于我认为那些丢脸的标记不轻易懂得。

清单 5. Henri Sivonen 建议但本文作者不批准的精致打印方法

>bar>

修道院的建议

现在换换档，本文要探讨的第二篇材料是 Simon St. Laurent 撰写的“Monastic XML”（请参阅参考材料）。这是一组小短文，缭绕着如何充分利用 XML 而就处理和思考 XML 提出了一些建议。Simon 应用修道院和禁欲主义作为比喻，提出为 XML 增加不适应其简略文本根 (textual root) 的过多累赘是危险的。 在“Marking-up at the foundation”中,他讨论了字符数据和标记（元素和属性）的本质作用。在“Naming things and reading names”中，他说明了为何一般标识符（也称为元素类型名）是一个重要的概念，应当作为标记信息结构的惟一要害成分。幻想情况下，假如应用 XML 名称空间，要害就是同一名称（名称空间 URI 加上本地名），这种复杂化就是 Simon 在“Namespaces as opportunity”中厉声疾呼的原因之一。“Accepting the discipline of trees”揭示了 XML 一个不幸的机密：尽管看起来 XML 的层次结构很轻易扩大成图形结构，但实践证实用 XML 建模图有点艰苦。但目前为止，“Monastic XML”网站上最重要的建议是“优化标记的处理总是不成熟”。XML 是一种声明性技巧，对很多开发职员来说，关于它的强盛和不足有很多不实之词。那些尽量把 XML 设计和处理细节拉近的开发职员，从长期来看，通常使得处理更加艰苦。XML 成功的要害是关注需要抽象表现的信息的特点，将它与需要处理这些信息的系统的技巧设计分别开来。