ACM通信

实践

XML发烧

作者:埃里克·王尔德，罗伯特·j·格卢什科
ACM通信，2008年7月，第51卷第7期，第40-46页
10.1145/1364782.1364795
评论

可扩展标记语言(XML)，刚刚庆祝了它的10周年^th的生日,⁴是网络最成功的故事之一。除了基本的Web技术(uri、HTTP和HTML)和推动Web 2.0浪潮的高级脚本之外，XML是迄今为止最成功、最普遍的Web技术。然而，功能越大，责任也越大，因此，尽管XML作为第一个真正通用的结构化数据标准获得了成功，但它现在必须处理围绕它产生的许多问题。这并不完全是XML本身的错，相反，可以归咎于对XML是什么以及它能做什么的夸大的主张和想法。

本文将介绍从学习XML、教授XML、处理对XML功能过于乐观的假设以及帮助现实世界中的XML用户从这些错误观念中恢复所获得的经验教训。无耻地抄袭亚历克斯·贝尔的《死于UML狂热》¹我们根据“XML热”的不同类别和类型，将我们的观察结果和问题的根源以及可能的解决方法框定。这个术语不是我们发明的，但它包含了许多有趣的隐喻，用于理解XML的使用和滥用，包括疾病症状、感染方法、免疫和预防措施，以及治疗不同疾病的各种补救措施。

XML热可以通过许多不同的方式获得，但最普遍的方式是受到这样一种思想的感染，即XML几乎可以实现信息生产者和消费者之间神奇的通用互操作性。XML狂热可以分为基本的、中级的和高级的:

基本的菌株会感染XML新手，但大多数都能很快恢复。发现XML技术的前景并不像预期的那样简单，使用相关工具需要一些习惯，这可能会令人失望，但大多数人对XML的宣传产生了一定的免疫力，并很快开始使用它进行有用的工作。

中间压力当XML用户超越了包含结构化信息的简单应用程序，并遇到数据、文档或过程的模型时，XML热就会减弱。在这些XML热潮中反复出现的症状是，由于必须选择一种模式语言来编码模型、试图在某些语言中令人眼花缭乱的特性中进行选择，或者试图在不同环境之间“往返”模型，从而导致了轻微的瘫痪。

先进的压力XML热通常是在接触到更复杂、更深奥的基于XML的技术的激增之后形成的。这些晚期疾病更难感染，但也更难治愈，因为感染了这些晚期菌株的人往往与患有相同疾病的人聚集在一起，他们不断地相互感染。

回到顶部

基本的菌株

我们最喜欢的教学时刻之一是在XML入门课开始时，用这样一句话开始，“XML是树的语法”，这就是它的全部内容，因此不需要进一步解释。当然，它还有更多的内容，我们设法用它填满一门完整的课程，但XML的本质确实是简单和小的。这对我们来说是优雅的，但对许多XML初学者来说是失望的，他们希望有更大更复杂的东西来匹配他们所听到的所有宣传。事实上，XML基于字符的格式诱使许多XML初学者认为他们可以简单地使用他们信任的文本处理工具，这是第一次XML热的不可避免的路径:

解析的痛苦。乍一看，XML的语法似乎很容易使用简单的文本处理工具来访问XML数据，因此“绝望的Perl黑客”可以在一个周末实现XML。不幸的是，并非所有XML文档都使用相同的字符编码;人物引用必须有解释;实体必须被解决;等等……一旦考虑了来自更广泛的XML生成器的输出，显然，为了使用文本处理工具进行健壮的XML解析，这些工具必须实现一个完整的XML解析器。当XML处理需要考虑XML名称空间时，这一点就变得尤为明显(通常会导致染上中间名称空间恐惧症)。

在克服了解析的痛苦并开始使用XML解析器之后，初学者通常会理解我们所说的XML是树的语法是什么意思，但他们不会很快理解XML使用多个树模型，而且根据使用的XML技术，“XML树”看起来略有不同。因此，XML热潮的第二种基本类型是:

树的创伤。这是由于使用XML的各种树模型造成的，例如XML本身、DOM、Infoset、XPath 1.0、PSVI和XDM。所有这些树模型都共享XML的元素树、属性树和文本树的基本思想，但在公开模型和处理某些细节方面有不同的方法。事实上，尽管XML本身显式地声明XML处理器必须实现所有XML(除了验证之外，标准没有可选部分，这是标准应该做的一件聪明的事情)，但一些较新的树模型表现出技术的“扩展子集”特性，这经常会导致实现之间的不兼容。例如，psvipsvi是由XML模式(在本文的其余部分，我们将W3C语言称为XSDL)验证的XML文档的数据模型，它基于Infoset, Infoset是XML文档全部信息的子集，并使用模式和验证过程提供的信息扩展该子集。

虽然XML有许多不同的“树风格”，但W3C(经过非常长的过程)确定了Infoset模型作为许多XML技术的核心。这意味着在技术上更准确地说，目前可用的大多数XML技术实际上都是Infoset技术。XML已经成为表示Infoset的一种方法(到目前为止也是唯一的标准化方法，但即将出现的二进制Infoset格式EXI是一种更紧凑的替代方法)。当然，W3C不想放弃XML的品牌名称，仍然称一切为“基于XML的”。因此，XML用户很容易受到一种特殊疾病的影响:

Infoset无知。这些技术的确切名称应该是IPath、ISLT和IQuery，而不是XPath、XSLT和XQuery，因为它们是基于infoset的。Infoset无知的受害者只从表面上看W3C把所有东西都标记为XML，有时投入大量精力试图构建XML处理管道，以保存字符引用和其他标记细节。对信息集的无知使它的受害者看不到，只要他们使用的是基于标准的工具，这种方法就不会成功。

弥补Infoset无知的方法是选择一组具有兼容树模型的XML技术。这通常还可以治愈树创伤，因为现在XML用户可以专注于特定种类的XML树。但是，根据所选择的特定技术，树创伤可能会由于未能理解某些XML技术处理树的模糊方式而转移为更严重的疾病:

默认的错乱。如果XML用户接触并尝试了dtd和XSDL等允许默认值的模式语言，树创伤可能发展成默认紊乱。这些语言导致XML树根据验证进行更改，这意味着XML处理非常依赖于验证。由于隔离XML用户以使其远离这些模式语言通常是不可实现的，因此更好的方法是严格遵守设计准则，以避免这些潜在的危险特性。

如今几乎所有XML场景的核心组件都是XML名称空间。它们对于将XML的本地名称转换为全局唯一标识符至关重要，但是如何在文档中声明名称空间，以及名称空间名称是uri，不需要解引用这一事实，还没有失败过一次，使试图开始使用它们的每个人感到困惑。因此，非常流行的XML热是:

名称空间恶心。无论我们多么频繁地试图解释XML名称空间除了本地名称和名称空间名称的简单关联之外没有其他功能，围绕着它们还是有许多误解和假设。例如，许多学生认为名称空间必须引用现有资源，并问我们如何“在程序中调用名称空间”。尽管XML应该很简单，但它们通常是由不允许对名称空间的处理方式进行太多控制的工具序列化的，因此创建的XML文档展示了各种正确但非常令人困惑的名称空间使用方法。当使用特定类型的XML词汇表时，可能会出现由名称空间恶心引起的特别严重的二次感染:

上下文白内障。如果qname(结合名称空间前缀和本地名称的冒号分隔的名称)被允许作为XML文档的内容出现(例如在属性值或元素内容中)，那么它们将使内容依赖于上下文。这意味着这样的XML内容只能在XML文档的上下文中被正确解释(所有作用域内名称空间声明都可以被访问)，或者必须通过解析并将每个QName替换为与上下文无关的表示来对其进行去文本化。不幸的是，没有针对后一种方法的标准，这使得这种上下文化的内容很脆弱，很难使用。

到目前为止所描述的压力表现在基本的XML处理任务中。一旦XML用户开始使用业务信息和流程，他们就必须面对理解XML结构实际含义的挑战。这一任务使他们暴露于一种危险的病毒，这种病毒用朗朗上口的口号编码，即XML是“自我描述的”。

我们可以宽容地假设，当人们说XML是自我描述的，他们真正的意思是“与其他显然不是这样的东西相比”。自我描述最少的信息仅仅是由一些文本格式的字母数字字符组成，就像打孔卡上的字符一样。这种无分隔符的编码甚至没有显式地将字符标记为有意义的值，因此不存在任何可以分配描述的“自我”。只有当我们用逗号或其他分隔符分隔值时，才有可能出现自我描述，这告诉我们必须描述哪些信息组件。XML更进一步，使用成对文本标签的语法机制来区分文本流中的信息组件，并使用引号将一个信息位关联为另一个信息位的属性。可以肯定地说，XML平均而言比其他基于文本的编码语法更能自我描述，但这就好比说一般的侏儒比一般的婴儿高;他们都不够高，打不出篮球来。

---

虽然XML作为第一个结构化数据的真正通用标准获得了成功，但它现在必须处理围绕它产生的许多问题。这并不完全是XML本身的错，相反，可以归咎于对XML是什么以及它能做什么的夸大的主张和想法。

---

从更技术的角度来看，XML在有限的意义上是自我描述的，即数据结构(XML树之一，参见树创伤)可以从XML文档(以及它的模式，如果处理发生在易受默认紊乱影响的环境中)重构。

然而，当大多数人说XML是自描述的时，他们被一种错觉所捕获，认为这指的是实际的语义，而忽略了XML几乎没有预定义的语义(唯一的例外是用于标识语言的预定义属性)。这种疾病最有可能是由许多XML示例引起的，这些示例显示的元素和属性名似乎是自描述的，因为它们标记了语法组件。以下例子可以防止这种情况的发生:XML标记字符如何将被描述的信息与作为其结构描述一部分的标记区分开来:

使用语法机制来提供元素和属性语义的线索是很方便的，但这是一种非常常见的XML狂热的原因:

自我描述的错觉。XML为元素和属性定义名称的能力，以及认为这些名称具有某些内在语义的普遍假设，常常导致受害者认为XML文档的语义是不言而喻的，只要查看并理解名称就可以公开获得。通常，当受害者了解到XML不处理语义，而必须通过其他机制建立共同理解时，这种XML狂热会引起极大的不适。因自我描述错觉而虚弱的患者往往感染一种或多种XML热的中晚期菌株，这种菌株有望轻松而永久地治愈自我描述错觉造成的痛苦。

从自我描述错觉中恢复需要大量的个人承诺和努力。受害者必须学习如何定义或适应XML词汇表，或者采用明确关注语义而不仅仅是语法的技术。无论哪种情况，这些步骤都有可能导致基本类型以外的XML热潮。

回到顶部

中间压力

如果自我描述错觉得到了适当的诊断和治疗，XML用户通常会恢复并获得更好的洞察力。他们现在认识到XML的基本技术和工具集可以用于涉及结构化数据的基本处理任务，但是大多数应用程序都涉及到应用程序数据或过程的模型。XML基于树形结构作为基本模型，这并不总是最适合应用程序级模型，这在将这些非树形结构映射到XML时可能会造成麻烦:

树地震。“树创伤”(前面讨论过)是XML技术中各种各样的树引起的XML热的一种基本类型，而“树震颤”则是一种更严重的情况，它会折磨试图在XML中管理固有不是树结构的数据的受害者。最常见的原因是数据模型需要非树状图结构，文档模型需要重叠结构。在这两种情况下，将这些模型映射到XML的树模型会导致XML结构不能方便地表示应用程序级模型。

我们经常告诉学生，“XML的最大优点是可以轻松地创建新词汇表。”但是，由于XML允许格式良好的文档(与必须符合某些模式的有效文档相反)，因此实际上可以使用从未显式创建的词汇表:文档可以简单地在任何地方使用从未声明(更不用说定义了)的元素和属性。在原型开发过程中，格式良好是合适的，但在部署过程中是鲁莽的，几乎肯定会破坏互操作性。不幸的是，许多XML用户都有一种情况，使他们无法看到这些危险:

近视模型。从基于格式良好的文档的原型开始，一些开发人员从不费心开发模式，更不用说这种模式和应用程序级数据模型之间定义良好的映射了。在导致这种情况的场景中，验证通常只靠肉眼(该技术的关键短语是“在我看来不错”或“我们的文档通常看起来像这里的两个示例”)，这使得不可能严格地测试文档的正确性。xml到模型的往返转换和反向转换不能可靠地实现，并且假设和黑客被内置到系统中，这将不可避免地导致以后的互操作性问题。

如果诊断出模型近视(通常是发现两个实现不能正确地互操作，因为这些实现中内置了不同的假设集)，那么治愈它的关键步骤是定义一个模式，以便文档中使用的XML结构定义良好，并且可以使用现有工具进行验证。一旦发生这种情况，一个明显的问题就是使用哪种模式语言。这可能是另一个麻烦发展的开始:

模式的精神分裂症。dtd是XML的内置模式语言，但它们的表达能力有限，不支持基本的XML特性(最明显的是，它们不能很好地与XML名称空间一起工作)。在考虑了各种备选语言之后，W3C最终选定了XSDL，这是一种具有内置建模功能的相当复杂的模式语言。XSDL的表达能力可能直接导致相关的感染，原因是无法在建模方案之间做出选择:

Schema选项瘫痪。XSDL的复杂性允许以多种方式对给定的逻辑模型进行编码(这种狂热将在即将到来的XSDL 1.1中演变成更严重的威胁，它添加了与现有功能重叠的新功能)。解决模式选项瘫痪的一种方法是使用具有更好分离关注点的替代模式语言(比如将自身限制在语法中，而将数据类型和基于路径的约束留给其他语言)，最著名的是RELAX NG。

使用更集中的模式语言和以关注点分离为目标，模式开发人员可以选择模式语言。此外，有时结合模式语言来捕获比任何一种语言单独执行的更多的约束是最理想的。然而，模式语言的选择通常更多地取决于可用的工具支持和后天习得的习惯，而不是通过对最合适的语言的彻底分析来决定。

由于模式精神分裂症(偶尔会出现模式选项瘫痪)可能是一种痛苦而持久的状况，因此一个诱人的解决方法是不使用模式语言作为模型的规范编码形式，而是从一些更面向应用程序的建模环境或工具生成模式。然而，这些工具通常有不同的内置偏好，它们很少支持文档建模。这会给生成的模式带来一个非常特殊的问题:

混合内容危机。XML的起源是一种文档表示语言，这使它能够表示复杂的文档结构，特别是混合内容，这在出版物和其他叙述文档类型中是必不可少的。然而，大多数非xml建模环境和工具都是面向数据的，缺乏对混合内容的支持。这些工具生成的XML结构看起来像关系数据库中的表转储，缺乏在文档处理环境中至关重要的微妙的文档结构。

因为生成模式的方法的优点是XML模式的开发人员不必实际编写它们(甚至不必查看它们)，所以它也可能是最令人烦恼的XML问题之一的原因，当遇到从UML模型或电子表格生成的模式时，经常会遇到这种问题:

生成的模式消化不良。为了进行基于XML的信息交换，必须将更抽象的模型映射到XML词汇表。大多数建模工具和开发环境将模型导出到XSDL，并使用该模式对实例进行序列化和解析。然而，由于模式精神分裂症的危害性，这种模型到模式的编码是复杂的和依赖于工具的。生成模式消化不良通常会折磨那些试图在生成模式或实例的工具的上下文中使用模式或实例的人。第一次接触生成的模式可能会非常令人沮丧和反感，因为除非在这两种上下文中遵循相同的XML编码规则，否则XML可能不容易使用，而且肯定既不可互操作也不可扩展。

这些XML狂热的中间类型主要围绕着如何创建和使用定义良好的XML词汇表描述的问题。在我们继续描述这些中间狂热症可能导致的更高级的XML狂热症以及试图治愈它们之前，必须指出避免这种狂热症的好方法是重用现有的XML语言，从而避免发明新东西的努力和风险。

在《论语言创作》的在线后续文章中，^3.Tim Bray (XML的创建者之一)说:“如果要设计一种新的XML语言，首先要考虑不要这样做。”这一点非常重要，因为XML的普遍存在使得对于任何给定的问题，其他人可能已经遇到过它并解决了它。或者对于一个给定的问题，可以将其划分为更小的部分，或者将其映射到一个更普遍的问题，并为这些问题找到现有的解决方案。

当然，也有可能之前的工作不存在，或者可用的解决方案不令人满意，但是评估现有的解决方案确实是值得的，因为一个词汇表可以代表数百甚至数千小时的分析和编码。例如，通用业务语言(UBL)是一组业务事务通用的信息构建块和几十个重用它们的标准文档，是众多XML和业务专家多年工作的结果，UBL工作本身始于2001年，建立在XML通用业务库(xCBL)的基础上，该工作始于1997年。

我们总是告诉学生XML最糟糕的地方和最好的地方是一样的:创建新词汇表的便利性。语言设计从根本上来说是困难的，但是XML通过降低语法阈值使其看起来很简单。创建全局理解的、在所有必要方面都定义良好的、易于使用的共享词汇表的概念性任务并没有因为XML而变得更容易。XML刚刚为我们提供了一个很好的工具集来描述和使用这些语言，但是定义它们仍然是一项艰巨的工作。

当然，这对计算机科学家来说并不是什么秘密，当XML对于有意义的信息交换至关重要时，它没有语义，这一事实导致了语义Web的想法。²语义Web的价值主张是引人注目的:一种表示语义的通用方法使表达、理解、交换、共享、合并和达成一致变得更容易。然而，语义Web也是更高级的XML热潮的主要原因。

---

我们总是告诉学生XML最糟糕的地方和最好的地方是一样的:创建新词汇表的便利性。

---

回到顶部

先进的压力

如果语义很重要，而且XML模式只定义结构(即语法)，那么必须以其他方式指定语义。这可以通过描述模式的各个组件和部分的含义来非正式地实现，也可以通过使用一些用于指定语义的模型来更正式地实现。语义网是这种环境中最受欢迎的候选者;它基于一种用于制作关于资源的语句的模型，即资源描述框架(RDF)，并在此基础上添加了各种技术，例如用于描述RDF模式的技术。

关于语义Web的一个经常被忽视的重要观察是，它不仅引入了语义模型(RDF的各种模式语言)，而且还引入了新的数据模型，这意味着XML的树形结构不再是表示数据的核心数据结构。RDF可以用XML表示，但是有许多不同的方法来实现它，这可能会导致非常特定的问题:

RDF的愤怒。RDF最广泛使用的语法是基于XML的，但是有许多不同的方法可以将同一组RDF三元组表示为XML，因此使用基本的XML工具处理RDF数据几乎是不可能的，甚至对于比较RDF数据这样的简单任务也是如此。无法将看似相关的工具集用于看似相关的任务，这通常是XML用户了解到他们现在患上了更高级的XML热的第一个症状。

在更经典的信息组织观点中，术语的含义可以通过多种方式指定。按照复杂性排序，流行的方法是受控词汇表、分类法、词汇表和本体。RDF可以用于实现这些概念中的任何一个，但是RDF模式通常被称为本体。这在一定程度上是基于标准的免费工具的结果，用于创建诸如Protégé和SWOOP等本体;就像我们提到的模式选项麻痹一样，工具的可用性决定了人们使用的语言和他们所做的选择。然而，“本体论”世界的相对不熟悉和模糊的“时髦”会让XML用户担心他们适应具有更严格语义的RDF/OWL世界的能力。因此，他们经常过度补偿:

本体过度。在一个关注语义的环境中，本体过度杀死的受害者往往会对语义进行过度建模，创建对应用程序没有什么价值的抽象和关联，但会使模型更加难以理解和使用。本体过度扼杀迫使其受害者不仅过度建模，而且常常在这样做上失败，因为定义一个本体(在其完全意义上)、识别、理解和验证其所有含义要比定义一个受控词汇表困难得多。

如果XML狂热者接触到语义Web思想广泛传播和建立良好的社区，他们很快就会发现，他们在XML学习曲线的基础和中间阶段获得的大多数知识不再适用。这样做的原因是语义Web在其他Web技术之上创建了一个完全自包含的世界，唯一的交集是资源由URI标识。结果，语义Web用户变得幸福地不知道Web可能为他们提供解决方案，或者可能有更简单的解决问题的方法。将语义Web视为Web进化的合乎逻辑的下一步，我们可以观察到以下情况:

Web失明。在这种情况下，受害者适应语义网的程度达到了非语义网甚至不存在的程度。在纯语义Web中，底层技术不再需要发展，因为每个问题都可以在语义层上解决。网络盲症的受害者通常只是模糊地意识到，现实世界中的许多问题是，而且最有可能通过语义Web技术以外的技术来解决。

如果Web盲区的受害者已经适应了丰富的RDF新环境，并开始接受新世界，那么他们可能会接触到聚集了大量RDF数据的应用程序。虽然RDF三元组是一个看似简单的概念，但RDF的真正威力在于，这些三元组被组合起来形成关于事物的语句和关于语句的语句的相互连接的图，这使得没有专门的工具就无法使用这个数据集。这些工具需要专门的数据存储和专门的语言来访问这些存储。处理这些大数据集是rdf特有问题的主要原因:

三重打击。尽管RDF本身很简单，但大型数据集很容易包含数百万个三元组(对于真正的大型数据集，这可能高达数十亿个三元组)，管理和查询如此大的数据集可能成为一个相当大的挑战。如果这些大型数据集的模式很简单，但是本体过度消耗已经出现，并且已经被重新表述为本体，那么处理这个数据集可能会变得相当困难，没有任何直接的好处。

对于需要完全开发的本体的项目来说，语义Web技术可能是正确的选择，但是语义Web技术与普通Web和XML关系不大。这意味着这两种方法都不能治愈基本的或中间的XML狂热，而且每种方法都有自己的一组问题，这里只部分列出了这些问题。

回到顶部

处方

我们可能无法阻止这些XML热的变种，特别是基本的变种，因为这无疑是对XML的大肆宣传和过分宽泛的主张的结果，许多人首先尝试了它。但是，通过教导XML技术的适当使用取决于所应用问题的性质和范围，我们可以更好地为XML新手和用户预防中级和高级变种。重量级XML规范(如OASIS、OMG和其他标准组织开发的规范)是构建健壮的企业级XML应用程序所必需的，而语义Web概念和工具是知识密集型计算的先决条件，但在其他上下文中，更轻量级的信息结构化和分类方法(如微格式)也可以。

当人们第一次了解XML时，XML可能看起来像cliché中的锤子，所有东西看起来都像钉子。然而，我们这些教授XML、撰写XML知识或帮助其他人成为XML的有效用户的人，可以鼓励对XML工具和技术有一种更细致的看法，将它们描述为一组大小不同、有各种握把、头部和爪子的锤子。我们需要指出，不是每个人都需要一套完整的“锤子”，但是信息架构师应该知道如何为他们需要的“锤子”类型选择合适的“锤子”。我们应该永远记住，敲钉子只是设计和施工中涉及的任务之一。

作为一种以开放和容易计算的方式编码信息的方便格式，XML的成功超出了最疯狂的预期。但它只是一种格式，分析和建模信息的困难工作没有消失，也永远不会消失。

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2008 ACM, Inc.