XML 狂热

2008年12月4日
第6卷，第6期

不要让对 XML 的错觉发展成 XML 狂热的毒性变种。

Erik Wilde 和 Robert J. Glushko，加州大学伯克利分校

XML（可扩展标记语言）刚刚庆祝了它的 10 周年⁴，它是 Web 的重大成功案例之一。除了基本的 Web 技术（URI、HTTP 和 HTML）以及驱动 Web 2.0 浪潮的高级脚本之外，XML 是迄今为止最成功和最普遍的 Web 技术。然而，强大的力量伴随着重大的责任，因此，虽然 XML 作为结构化数据的第一个真正通用标准而获得的成功是当之无愧的，但它现在必须处理围绕它产生的众多问题。这些问题并非完全是 XML 本身造成的，而是可以归因于对 XML 是什么以及它可以做什么的夸大其词和想法。

本文讲述了从学习 XML、教授 XML、处理对 XML 功能的过度乐观假设以及帮助现实世界中的 XML 用户从这些误解中恢复过来而吸取的教训。我们无耻地抄袭了 Alex Bell 的“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 的各种树模型引起的，例如 XML 本身、DOM（文档对象模型）、Infoset、XPath 1.0、PSVI（后模式验证信息集）和 XDM（XQuery 1.0 和 XPath 2.0 数据模型）。所有这些树模型都共享 XML 的基本思想，即元素、属性和文本的树，但具有不同的方式来暴露该模型并处理一些细节。事实上，虽然 XML 本身明确声明 XML 处理器必须实现所有 XML（除了验证，标准没有可选部分，这对标准来说是一件聪明的事情），但一些较新的树模型表现出技术的“扩展子集”性质，这通常会导致实现之间的不兼容性。例如，PSVI——由 XML 模式（对于本文的其余部分，我们将 W3C 的语言称为 XSD）验证的 XML 文档的数据模型——基于 Infoset，它是 XML 文档的完整信息的子集，并使用模式和验证过程提供的信息扩展该子集。

虽然 XML 以多种“树风格”提供，但 W3C（经过漫长的过程后）已将 Infoset 模型确定为许多 XML 技术的核心。这意味着从技术上讲，更准确地说，当今可用的大多数 XML 技术实际上都是 Infoset 技术。XML 已成为表示 Infoset 的一种方式（到目前为止是唯一标准化的方式，尽管即将推出的二进制 Infoset 格式 EXI 是一种更紧凑的替代方案）。当然，W3C 不想放弃 XML 的品牌名称，仍然将一切都称为“基于 XML 的”。因此，XML 用户很容易受到一种特殊的疾病的影响

Infoset 无知。XPath、XSLT 和 XQuery 这些技术的正确名称应该是 IPath、ISLT 和 IQuery，因为它们是基于 Infoset 的。Infoset 无知的受害者将 W3C 将一切都标记为 XML 的做法信以为真，有时会投入大量精力来构建 XML 处理管道，以保留字符引用和其他标记细节。Infoset 无知阻止其受害者看到，只要他们使用基于标准的工具，这种方法就不会成功。

Infoset 无知的补救措施是选择一组具有兼容树模型的 XML 技术。这通常也会治愈树创伤，因为现在 XML 用户可以专注于 XML 树的特定变种。然而，根据选择的特定技术，树创伤可能会转移为更严重的疾病，这是由于未能理解某些 XML 技术处理树的有些晦涩的方式而引起的

默认错乱。如果 XML 用户接触并尝试使用诸如 DTD（文档类型定义）和 XSD 等允许默认值的模式语言，树创伤可能会发展成默认错乱。这些语言会导致 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 标记字符如何区分被描述的信息与作为其结构描述一部分的标记的示例来预防它

<xxx yyy="4567">850</xxx>

   <zzz>20060812</zzz>

使用句法机制来提供元素和属性语义的线索很方便，但这是非常常见的 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 最终确定了 XSD，这是一种相当复杂的模式语言，具有内置的建模能力。XSD 的表达能力可以直接导致相关的感染，这是由于无法在建模替代方案之间做出决定而引起的

模式选项麻痹。XSD 的复杂性允许以多种方式编码给定的逻辑模型（随着即将推出的 XSD 1.1，这种狂热将突变成更严重的威胁，XSD 1.1 添加了与现有功能重叠的新功能）。治愈模式选项麻痹的方法是使用关注点分离更好的替代模式语言（例如，将自身限制为语法，并将数据类型和基于路径的约束留给其他语言），最值得注意的是 RELAX NG。

使用更专注的模式语言并针对关注点分离，使模式开发人员可以选择模式语言。此外，有时最好组合模式语言以捕获比任何一种语言本身可以强制执行的更多约束。然而，模式语言的选择更多地取决于可用的工具支持和已养成的习惯，而不是对什么是最合适的语言进行彻底分析。

由于模式精神分裂症（偶尔发作模式选项麻痹）可能是一种痛苦且持久的疾病，因此一种诱人的出路是不使用模式语言作为模型的规范编码形式，而是从某些更面向应用程序的建模环境或工具生成模式。然而，这些工具通常具有不同的内置偏见，并且它们很少支持文档建模。这为生成的模式带来了一个非常具体的问题

混合内容危机。XML 作为文档表示语言的起源赋予了它表示复杂文档结构的能力，最值得注意的是混合内容，这在出版物和其他叙事文档类型中至关重要。然而，大多数非 XML 建模环境和工具都是面向数据的，并且缺乏对混合内容的支持。这些工具生成的 XML 结构看起来像是关系数据库中的表转储，缺乏在文档处理环境中至关重要的细致的文档结构。

由于生成模式的方法具有 XML 模式开发人员永远不必实际编写它们（甚至不必查看它们）的优点，因此它也可能是最令人困扰的 XML 问题之一的原因，这些问题通常在遇到从 UML 模型或电子表格生成的模式时会遇到

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

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

在对“关于语言创建”³的在线跟进中，Tim Bray（XML 的创建者之一）说，“如果你要设计一种新的 XML 语言，首先，考虑不要这样做。”这是一个非常重要的观点，因为 XML 的普遍性使得对于任何给定的问题，其他人可能已经遇到并解决了它。或者对于给定的问题，可能可以将它分成更小的部分，或者将它映射到一个更普遍的问题，并找到这些问题的现有解决方案。

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

我们总是告诉学生，关于 XML 最糟糕的事情与最好的事情相同：你可以轻松地创建新词汇表。语言设计从根本上来说是困难的，但 XML 通过降低句法门槛，使其具有欺骗性的简单性。创建全局理解、在各个必要方面明确定义且相对易于使用的共享词汇表的概念性任务并没有因 XML 而变得更容易。XML 只是为我们提供了一套很好的工具集来描述和使用这些语言，一旦我们拥有了它们，但是定义它们仍然是一项艰苦的工作。

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

高级型变种

如果语义很重要，并且由于 XML 模式仅定义结构（即语法），那么语义必须以其他某种方式指定。这可以通过散文非正式地描述模式的各个组件和部分的含义，或者更正式地，通过使用某种模型来指定语义来实现。语义 Web 是这种环境最流行的候选者；它基于一种用于对资源、RDF（资源描述框架）进行陈述的模型，其上分层了各种技术，例如用于描述 RDF 模式的技术。

关于语义 Web 的一个经常被忽略的重要观察是，它不仅引入了语义模型（RDF 的各种模式语言），还引入了一种新的数据模型，这意味着 XML 的树结构不再是表示数据的核心数据结构。RDF 可以用 XML 表示，但有很多不同的方法可以做到这一点，这可能会导致一种非常特殊的疾病

RDF 狂暴。RDF 最广泛使用的语法是基于 XML 的，但是同一组 RDF 三元组可以用 XML 以多种不同的方式表示，因此即使对于比较 RDF 数据等简单任务，使用基本的 XML 工具几乎是不可能处理 RDF 数据的。这种无法对看似相关的任务使用看似相关的工具集的情况，通常是 XML 用户了解到他们现在患有更高级的 XML 狂热变种的第一个症状。

在信息组织的更经典视图中，术语的含义可以用多种方式指定。按复杂程度排序，流行的方法是受控词汇表、分类法、同义词库和本体。RDF 可以用于实现这些概念中的任何一个，但 RDF 模式最常被称为本体。这部分是由于用于创建本体的免费的基于标准的工具（例如 Protégé 和 SWOOP）；正如我们在模式选项麻痹中提到的那样，工具的可用性塑造了人们使用的语言和他们做出的选择。“本体”世界的相对陌生和模糊的“时尚性”可能会让 XML 用户对其调整到具有更严格语义的 RDF/OWL（Web 本体语言）世界的能力感到焦虑。因此，他们经常过度补偿

本体过度杀伤。在关注语义的环境中操作，本体过度杀伤的受害者倾向于过度建模语义，创建对应用程序几乎没有价值但使模型更难理解和使用的抽象和关联。本体过度杀伤迫使其患者不仅过度建模，而且经常在这样做时失败，因为定义本体（在其最完整的意义上）并识别、理解和验证其所有含义比定义受控词汇表要困难得多。

如果 XML 狂热患者接触到语义 Web 思想广泛且成熟的社区，他们很快就会发现他们在 XML 学习曲线的基本阶段和中级阶段获得的大部分知识不再适用。造成这种情况的原因是，语义 Web 在其他 Web 技术之上创建了一个完全独立的自包含世界，唯一的交集是资源由 URI 标识这一事实。因此，语义 Web 用户欣然不知 Web 可能有适合他们的解决方案，或者可能有更简单的方法来解决问题。将语义 Web 视为 Web 演进的逻辑下一步，我们可以观察到以下情况

Web 盲症。这是一种受害者沉迷于语义 Web 的程度，以至于非语义 Web 甚至不再存在的情况。在纯语义 Web 中，较低级别的技术不再需要发展，因为每个问题都可以在语义层解决。Web 盲症患者通常只是隐约意识到现实世界中的许多问题现在和最有可能在将来会使用语义 Web 技术以外的技术来解决。

如果 Web 盲症的受害者已经适应了他们丰富 RDF 的新环境并开始拥抱新世界，他们可能会接触到聚合了大量 RDF 数据集的应用程序。虽然 RDF 三元组似乎是一个简单的概念，但 RDF 的真正力量在于这些三元组被组合起来形成关于事物和关于陈述的陈述的互连图，这很快使得在没有专用工具的情况下不可能使用此数据集。这些工具需要专门的数据存储和专门的语言来访问这些存储。处理这些大型数据集是导致 RDF 特有疾病的主要原因

三元组冲击。虽然 RDF 本身很简单，但大型数据集很容易包含数百万个三元组（对于真正的大型数据集，这可能高达数十亿），并且管理和查询如此大的数据集可能成为一项相当大的挑战。如果大型数据集的模式很简单，但本体过度杀伤已经开始并将其重新表述为本体，则处理数据集可能会变得相当困难，而没有任何直接的好处。

语义 Web 技术可能是需要完全开发的本体的项目的正确选择，但语义 Web 技术与普通的 Web 和 XML 几乎无关。这意味着两者都不应被视为基本型或中级型 XML 狂热的疗法，并且每种都有自己的一系列问题，此处仅部分列出。

处方

我们可能无法预防这些类型的 XML 狂热，尤其是基本型变种，因为毫无疑问，这是许多人首先尝试 XML 的炒作和过度夸大主张的结果。但是，我们可以通过教导 XML 新手和用户 XML 技术的适当使用取决于它们所应用的问题的性质和范围，从而更好地为他们接种疫苗，以预防中级型和高级型变种。OASIS 和 OMG 开发的重型 XML 规范对于构建稳健的企业级 XML 应用程序是必要的，语义 Web 概念和工具是知识密集型计算的先决条件，但在其他上下文中，用于结构化和分类信息（如微格式）的更轻量级的方法就足够了。

当有人第一次了解 XML 时，XML 可能看起来像是关于一切看起来都像钉子的陈词滥调中的锤子。然而，我们这些教授 XML、撰写关于 XML 的文章或帮助他人成为 XML 的有效用户的人，可以鼓励对 XML 工具和技术采取更细致的看法，将它们描绘成一套不同尺寸的锤子，具有各种不同的握把、头部和爪子。我们需要指出，并非每个人都需要一套完整的锤子，但信息架构师应该知道如何为他们需要做的锤击类型选择合适的锤子。此外，我们应该始终记住，敲钉子只是设计和建造中涉及的任务之一。

XML 作为一种以开放且易于计算的方式编码信息的便捷格式，其成功超出了最疯狂的预期。然而，它只是一种格式，而分析和建模信息的艰苦工作并没有也不会消失。

参考文献

Bell, A.E. 2004. UML 狂热之死。 2(1): 72-80.
Berners-Lee, T., Hendler, J.A., Lassila, O. 2001. 语义 Web。科学美国人 284(5): 34-43.
Bray, T. 2005. 关于语言创建。在 XML 2005 会议论文集（佐治亚州亚特兰大，11 月）。
Bray, T., Paoli, J., Sperberg-McQueen, C. M. 1998. 可扩展标记语言 (XML) 1.0。万维网联盟，推荐 REC-xml-19980210（2 月）。

ERIK WILDE ([email protected]) 是加州大学伯克利分校信息学院的客座助理教授，同时也是信息和服务设计项目的技术总监。

ROBERT J. GLUSHKO ([email protected]) 是加州大学伯克利分校信息学院的兼职教授、文档工程中心主任，也是信息和服务设计项目的创始教员之一。

本文发表在 2008 年 7 月版的 Communications of the 印刷版中。

最初发表于 Queue vol. 6, no. 6—
在数字图书馆中评论本文

更多相关文章

Shylaja Nukala, Vivek Rau - 为什么 SRE 文档很重要
SRE（站点可靠性工程）是一种工作职能、一种思维模式以及一套工程方法，用于使 Web 产品和服务可靠地运行。SRE 在软件开发和系统工程的交叉点运作，以解决运营问题并设计解决方案，从而可扩展、可靠且高效地设计、构建和运行大型分布式系统。成熟的 SRE 团队可能拥有与许多 SRE 职能相关的明确定义的文档体系。

Taylor Savage - 组件化 Web
在当今的软件工程中，没有哪项任务能像 Web 开发那样艰巨。Web 应用程序的典型规范可能如下：该应用程序必须跨各种浏览器工作。它必须以 60 fps 的速度运行动画。它必须立即响应触摸。它必须符合特定的一组设计原则和规范。它必须在几乎所有可以想象的屏幕尺寸上工作，从电视和 30 英寸显示器到手机和手表表面。它必须在长期内得到良好的工程设计和可维护性。

Arie van Deursen - 超越页面对象：使用状态对象测试 Web 应用程序
Web 应用程序的端到端测试通常涉及通过 Selenium WebDriver 等框架与网页进行棘手的交互。隐藏此类网页复杂性的推荐方法是使用页面对象，但首先要回答一些问题：在测试 Web 应用程序时，应该创建哪些页面对象？页面对象中应该包含哪些操作？给定页面对象，应该指定哪些测试场景？

Rich Harris - 消除准入壁垒
在 Web 开发的世界中，一场战争正在进行。一方是工具开发者和工具使用者的先锋队，他们热衷于摒弃过时的旧观念（在这个环境中，“旧”指的是在 Hacker News 上发布超过一个月的任何事物）以及关于转译器及诸如此类的喧嚣辩论。