级别： 初级 Lee Feigenbaum, 顾问软件工程师, IBM
Elias Torres (eliast@us.ibm.com), 高级软件工程师, IBM
2007 年 2 月 15 日 在此系列文章中，我们通过大量实例全面地考察使人类和机器都能够轻松访问 Web 所发布的数据的现有技术和新兴技术。在本文中，我们考察并行 Web 的概念，看看 Web 内容发布者用于将人类可读的和机器可读的内容放到 Web 上的两种技术：HTML link 元素和 HTTP 内容协商。通过这两种技术，内容消费者可以在网页上各种不同的数据格式之间作出选择。回顾这些技术的历史，了解当前它们在 Web 上的部署情况，以及如何在一个示例场景 MissMASH 中使用并行 Web 将日历、银行和照片数据集成在一起。最后，我们对并行 Web 进行评估并得出结论，虽然这些技术已经成熟，也得到了广泛的部署，但是将机器可读的数据与相应的人类可读的内容分开仍然存在缺点。
在本文中，我们将谈到并行 Web 的概念。这个术语是指帮助内容发布者在 Web 上以两个或更多地址显示数据的技术。例如，一个地址可能存放人类可读的格式，而另一个地址存放机器可读的格式。此外，我们还谈到了在同一个位置以不同方式显示相同数据或资源，通过 HTTP 协议来对其做出选择的情况（参考资料 中有这方面的材料的链接）。
HTTP 和 HTML 是支撑万维网的两大核心技术，每个技术的规范中都包含一种流行的技术，支持备选内容表示的发现和协商。内容协商 是通过 HTTP 协议提供的，这种机制允许 Internet 上的用户代理和代理服务器/网关交换超媒体。在相同 Web 地址上存在不同的内容表示方式的场景中，可以看到这种技术的身影。在 HTML 页面中，link 元素表明包含页面的一种备选表示的一个位置。在本文的后续内容中，我们将看到这两种技术的一些历史，考察它们当前的部署和使用情况，解释如何应用它们来帮助解决 MissMASH 示例场景，并评估其强项和弱项，最后看看这两种技术适用的用例。
历史
几乎是从万维网本身诞生起，推动并行 Web 所需的技术就已经存在，这些技术被编入最初的 HTTP/1.0 和 HTML 1.0 规范中。然而，即使到今天，它们的部署、实现和应用仍然变化多端。例如，Apache Web 服务器是目前 Internet 上使用最广泛的 HTTP 服务器（参见参考资料），将近十年以来一直支持内容协商。但是，很少有站点真正包括内容协商配置和交替资源表示。相反，使用link元素指向页面的备选表示的网页却呈指数增长，尤其是随着在线日志和博客的发明，这一趋势更加明显。我们简要地考察一下这两种技术的起源，以便更好地理解它们是如何演变的，如何帮助创建对人和机器都有意义的 Web。
内容协商
既然对 Web 的构想就是让全球各行各业的人都能访问它，那么它就必须提供访问各种不同语言、字符集和媒体类型的超媒体的机制。例如，色弱的人可以配置他的用户代理（通常是 Web 浏览器），以便用文本文件表示网页上的图像。这种文本文件表示将包含描述图像的信息，可以被屏幕阅读软件使用，可能包括位置、个人姓名、日期等细节。另一方面，对于视力正常的人而言，一个标准的 Web 浏览器需要有浏览器能够显示的特定图像媒体类型的图像资源（例如 image/png 或 image/jpeg）。Web 要为各种各样的人服务，Web 上的信息的备选编码方式因此也呈多元化，HTTP 规范认识到这一点，并提供了内容协商机制来解决这个问题。
内容协商 这个词直到 HTTP/1.1 规范完成时才出现，但其核心功能在 HTTP/1.0 规范中就已经定义（参考资料中有这两个规范的链接）—— 不过并没有足够的描述。HTTP/1.0 规范为实现者提供了很小的一组混杂的头部：Accept、Accept-Charset、Accept-Encoding、Accept-Language 和 Content-Language。（在本文接下来的小节中，我们将涉及这些头部和它们的用法的更多技术细节。）
从历史上看，最初形式非常值得注意，内容协商机制完全由服务器从用户代理发送的选项所给出的所有可用组合中选择最佳表示。在内容协商接下来的版本（也就是当前版本，与 HTTP/1.1 同步）中，规范引入了根据最终决定备选表示格式、语言和编码的一方进行选择的机制。该规范提到服务器驱动的、代理驱动的 和透明的 协商。
服务器驱动的协商非常类似于最初的内容协商规范，但是有一些改进。代理驱动的协商是新出现的，它允许用户代理（可能需要用户的帮助）从服务器提供的列表中选择最佳表示方式。该选项并没有得到足够的描述，并且为了获得一个资源需要向服务器发出多个 HTTP 请求。因此，目前它还没有开始得到部署。最后，透明协商是前两种类型的混合体，但是非常不确定，因此目前也没有在 Web 上得到应用。
然而，虽然存在种种描述不足，HTTP/1.1 却引入了质量系数：介于 0 到 1 之间的浮点数，表示用户代理对一个给定参数的偏爱程度。例如，用户代理可以使用质量系数告诉服务器其用户在某些语言上的流利程度。然后，服务器可以结合备选语言表示的忠实性使用该信息，以便为请求选择最佳翻译，并将该翻译按照服务器驱动的协商进行交付。
到目前为止，您所看到的内容协商的示例都强调其为访问万维网的不同人提供服务的作用。但是，正如不同的人可以使用内容协商以有用的方式获取 Web 内容，不同的软件程序也会以机器可读的格式请求内容，以深化它们在 Web 上的实用性。在本文后面的内容中，您将看到如何使用内容协商使对人和机器都有意义的 Web 走得更远。
link 元素
和内容协商类似，为了满足并行 Web 的需求，link 元素也经历了一些演变阶段。在 HTML 规范的第一个阶段中，link 元素只有很少的属性，这些属性主要用于表明当前页与该元素的 href 属性引用的资源的位置之间的关系。其中大多数关系都是最初为导航功能设计的，但是 link 元素的关系总是可扩展的。虽然这些关系的语义和控制能力从来没有经过官方明确的定义，但是近年来却得到极其广泛的应用。现在，Internet Assigned Numbers Authority (IANA) 上甚至有一个进程和一个站点专门负责注册新关系（参见 参考资料）。
最值得注意的是，HTML 4.01 规范引入了一些新属性，它们可以指示 link 元素所引用的资源的媒体类型和字符集。正是由于增加了这些属性，link 元素才得到了更广泛地采用，尤其是在 Weblog 中大展身手。在本文的后面，您将看到，虽然 link 元素的很多传统用法都是以人的需求为中心的，但是，为了提升 Web 上软件的能力，这个元素已经越来越多地被用于引用机器可以使用的内容。
使用 link 元素
首先，我们来看一系列关于使用 link 元素的例子，同时也看看 link 元素的用法如何随着时间而演变，从而为机器提供对 HTML 页面编码的数据的更精确的访问。清单 1 使用 HTML 4.01 规范中定义的三种标准链接关系（要了解所有可用的链接类型，请参阅 参考资料），为网页读者提供导航提示。目前，典型的情况是，为了对文档进行导航，用户必须寻找合适的锚链接，这个锚链接可能被标记为 next，也可能被打上完全不同的标记，而如果发布者将上述附加的元数据包括到他们的页面中，那么对某些类型的文档，例如文章、书籍或帮助手册的导航会容易得多。
清单 1. 导航 link 元素
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>并行 Web</TITLE>
<LINK rel="Index" href="../meaningfulweb.html">
<LINK rel="Next" href="algorithmicapproach.html">
<LINK rel="Prev" href="../meaningfulweb.html">
</HEAD>
...the rest of the article...
|
在 清单 2 中，可以看到目前 link 元素的大多数流行的用法。大多数现代浏览器对层叠样式表（Cascading Style Sheets）规范有很好的支持，这种规范使发布者可以将 HTML 页面中的结构与表示分开，从而更容易更改其可视化表示，而不必重新编写整个页面。清单 2 中的例子使用了一个新属性：media，该属性为关联的样式信息指定预期的目标媒体。其默认值为 screen，但是也可以使用 print，或者，对于目标移动设备，可以使用 handheld。 （要了解关于这些值的更多信息，请参阅 参考资料。）注意：虽然可以在 media 属性中使用多个值，但是这些值之间必须以逗号隔开，而不是像 rel 属性的值那样使用空格作为分隔符。
清单 2. 提供指向样式表信息的链接
<HEAD>
<TITLE>并行 Web</TITLE>
<LINK rel="stylesheet"
media="screen,print"
type="text/css"
href="../dw.css">
</HEAD>
...the rest of the article...
|
接下来的例子使用 HTML 规范的国际化功能为浏览器或用户代理提供使用特定语言的导航信息，以便最大程度上与读者偏爱的语言相匹配。就拿这个文章系列来说，两个作者可以流利地讲两门语言。如果有很多讲西班牙语的读者，那么我们可以使用 link 元素为那些读者提供一个到这篇文章的西班牙语版的链接。
注意清单 3 中使用的一些属性和它们的值。首先，我们使用 alternate 链接类型来表达这篇文章与西班牙语版之间的关系。由于我们将该属性与 hreflang 属性一起使用，因此意味着被引用的网页是当前文档的经过翻译的备选版本。我们还添加了一个 lang 属性，以指定 title 属性的语言。最后，我们添加了一个 type 属性值，这是可选的，放在这里是作为给用户代理的一个咨询提示。（例如，Web 浏览器可以使用这个提示启动可以处理指定的媒体类型的注册应用程序。）
清单 3. 特定于语言的导航 link 元素
<HEAD>
<TITLE>并行 Web</TITLE>
<LINK rel="alternate"
lang="es"
title="La Red Paralela"
type="text/html"
hreflang="es"
href="es/redparalela.html">
</HEAD>
...the rest of the article...
|
前面的例子大多数都是展示 link 元素最常见的用法，但是，除了对 link 的特定于语言的使用外，这些例子并没有真正展示如何提供原始页面上的数据的备选表示。即使是在清单 3 中的语言例子中，备选表示也只是给人使用的，而不是给机器使用的。清单 4 中最后一个 link 例子展示 blog 如何使用 link 元素来引用 提要。提要是 HTML 文档的 XML 表示，与为个人呈现的 blog 的 HTML 内容相比，这种表示承载着更多的结构化语义。blog 阅读软件很容易提取出 XML 提要，以便按类型、日期或作者组织 blog 条目，并且为强大的搜索和过滤功能提供便利。如果没有 link 元素，软件就不能自动发现机器可读版本的 blog 内容，从而不能提供这种高级功能。这个例子很好地说明了这样一个问题：如果不使用并行 Web 技术，由人生成的内容（即使是通过 blog 发布工具生成）不容易被机器理解。link 元素启用的提要自动发现机制可以帮助人与机器在 Web 上共存。
在 清单 4 中，可以开始看到 link 元素所表现出来的威力，它通过解码当前 Web 上的内容，为机器提供有价值的信息。我们再次使用 "alternate" 关系标出一个新的 URL，在这个 URL 上可以找到当前显示的相同内容的替代表示。通过使用媒体类型，我们可以赋予用户代理选择最佳理解格式的能力 —— 不管它是 Atom 还是 RSS 提要，抑或是任何其它媒体格式。
清单 4 中显示的 link 元素创建了一个有三个节点的并行 Web。首先，在当前 URL 上是这篇文章供人使用的 HTML 表示。第二，相应的 URL ../feed/atom 包含相同内容的一个机器可读的版本，其格式为 application/atom+xml。最后，相应的 URL ../feed/rss 包含相同内容的另外一个机器可读的版本，这一次它的格式为 application/rdf+xml。
清单 4. 提供 blog 中指向提要 URL 的自动发现链接
<HEAD>
<TITLE>并行 Web</TITLE>
<LINK rel="alternate"
title="Atom 1.0 Feed"
type="application/atom+xml"
href="../feed/atom">
<LINK rel="alternate"
title="RSS Feed"
type="application/rdf+xml"
href="../feed/rss">
</HEAD>
...the rest of the article...
|
我们必须注意到，rel 属性的值并不局限于一个固定的集合。Web 社区不断试验新的值，这些值最终成为表达 HTML 页面与 href 属性 中指定的位置之间的新关系的事实上的标准。例如，WordPress blog 发布系统（参见 参考资料）使用的 pingback 值现在已经被非常广泛地使用。它为机器提供一个指针，该指针根据评论列表，指向连接不同 Weblog 条目的服务端点。
随着简单的基于 REST 的 Web 服务在 Web 上的散布，我们预见将会定义大量的 rel 值，用来指向很多不同的服务接口。link 元素的广泛使用大大增强了传统 Web 浏览器的功能，但是同时也带来涉及到关系类型的管理和一致性的诸多其它问题，不过这超出了本文的讨论范围。在 参考资料 中可以找到更多关于 HTML link 元素的信息。
使用内容协商
由于内容协商可能的复杂性，我们对内容协商的讨论不如 link 元素那么详细，但我们还是会详细谈到如何使用内容协商创建并行 Web。在本文的讨论中，我们将关注如何使用流行的 Apache HTTP Web 服务器软件配置内容协商。其它 Web 服务器软件的工作方式是类似的，底层概念是相同的。
通常，在 Web 上，URL 包含一个文件扩展名，这个扩展名或者表明用于产生 HTML 的方法（例如，.html 表示静态页面，.php 表示 PHP 脚本，.cgi 表示使用公共网关接口的各种脚本语言），或者表明 URL 上的内容的媒体格式（例如 .png、.pdf 或 .zip）。虽然这种方法在很多情况下适用，但是它要求为相同内容的每个不同表示创建和维护一个 URL。于是，这就要求使用某种机制将多个 URL 链接在一起（例如前面描述的 HTML link 元素，或者可以浏览的 a 锚链接元素），并且要求软件知道如何根据需要在不同 URL 之间作出选择。
内容协商允许：根据用户代理表明的它所能（希望）处理的媒体类型、字符集和语言，发送数据的不同表示来响应对 单个 URL 的请求。link 元素通过为相同内容的不同表示指定不同 URL 来构造并行 Web，而内容协商则不同，它支持这样一种并行 Web：其中相同内容的多种格式都在同一个 URL 上提供。本文的 参考资料 包含指向有关幕后 HTTP 内容协商的更多细节的链接。
Apache 提供了一个内容协商模块，其中有两个方法可用于根据以下 HTTP 请求选择资源的变种：类型映射（type map） 和 MultiViews。如果在 Apache 配置文件中使用类型映射，那么就使用它，根据语言、内容类型和字符编码的任意组合将 URL 映射到文件名。MultiViews 方法也类似，不同的是管理员不需要创建类型映射文件。相反，映射是根据服务器配置文档中指定的其它配置动态创建的。由于篇幅的关系，本文只展示一个类型映射的例子，要获得非常详细的 Apache 内容协商指南，请参阅 参考资料 中相关链接。
在 清单 5 中，我们列出了用来提供必要映射的类型映射的内容，这些必要映射根据语言和媒体类型的不同，提供我们文章的不同版本。在第 1 行，我们指定用于提供同一篇文章的多种格式和语言表示的一个 URI。第 3 行和第 4 行确定，在默认情况下，将使用文件 parallelweb.en.html，来响应所有对 text/html 媒体类型的请求。在第 6 行到第 9 行中，我们指定了一种特殊情况，即当用户代理提出相应要求时，可以提供文章的西班牙语版。接下来，在第 10 行和第 11 行，我们提供这篇文章的印刷版。最后，在第 13 行和第 14 行可以看到，软件可以检索这篇文章的 Atom 提要版本。通过使用内容协商，请求文章的 application/atom+xml 内容类型版本的 blog 阅读软件可以收到比标准 HTML 版本更易于软件理解的文章的表示。
清单 5. 使用 Apache 中的类型映射提供多种语言和格式的表示
[1] URI: parallelweb
[2]
[3] URI: parallelweb.en.html
[4] Content-type: text/html
[5]
[6] URI: parallelweb.es.html
[7] Content-type: text/html
[8] Content-language: es
[9]
[10] URI: parallelweb.ps
[11] Content-type: application/postscript; qs=0.8
[12]
[13] URI: parallelweb.xml
[14] Content-type: application/atom+xml
|
总之，这个服务器上的额外配置使我们的文章只需使用一个 URL，即可在用户代理提出请求时，提供对人友好和机器可读的数据。
现在来看看我们的示例应用程序，并设想如何使用并行 Web 技术来构建它。
例子：使用并行 Web 的 MissMASH
在这个系列的概述（参见 参考资料）中，我们提出了一个名为 MissMASH 的示例应用程序，它将用来阐释本系列中谈到的不同技术。这个应用程序的最终目标是，用户可以访问不同位置上的个人信息，这些信息都是使用基于日历的界面显示的。照片可能在 Flickr 上，在线银行结单可能来自 Citibank，日程安排细节则来自 Google Calendar。（参考资料 给出了这三个地方的链接）。我们的主要目的不是讲解这个应用程序的实际代码，而是要强调，使用不受任何示例数据提供者管理的软件，来帮助构建那样一个应用程序的主要机制。
请记住，由于并不是所有示例数据提供者都采用本系列文章中谈到的技术，因此这个场景中的某些部分将根据需要有所虚构。为 MissMASH 提供支持的软件所在的位置也并不重要。它可能是一个传统的、使用当代任意 Web 应用程序框架的服务器端 Web 应用程序，也可能是一个基于 Web 的、使用 Ajax（最近重新发现的，XML HTTP 请求 JavaScript 对象，参见参考资料）技术组合数据的客户端应用程序。无论如何，这种应用程序的关键在于，MissMASH 如何发现、标识和使用完成其目标所需的信息。理想情况下，它需要（人）用户提供的信息越少就越好。我们来看看并行 Web 如何帮助我们构建 MissMASH。
MissMASH 首先需要的信息之一是某种类型的在线日历帐户信息。正如您想象的那样，如果我们要求 MissMASH 理解 Internet 上每种可能的公共和/或私有日历服务的话，那么它很快就会变得笨拙起来。但是，如果这些服务使用并行 Web 技术，那么只需将访问该服务时从浏览器中看到的那个 URL 输入到 MissMASH 中即可。例如，考虑一下 Google Calendar。（对于当前的例子，我们将忽略用户身份验证方面的细节。）假设一个用户要配置 MissMASH，他在 Web 浏览器中导航到他的 Google Calendar，然后将浏览器地址栏中的 URL 复制并粘贴到 MissMASH 配置中。MissMASH 将请求那个 URL，解析返回的 HTML，并从中发现并行 Web 的一个好东西：一个 link 元素。
Google 提供了多种版本的在线日历：iCalendar（参见 参考资料）、Atom 提要 和 HTML。不幸的是，它只为 Atom 提要 版本的日历提供一个 link 元素，就像 清单 4 中描述的那样。对于 Flickr 也是一样的，它刚好也提供指向您的最新照片的 Atom 提要的一个链接。无论如何，MissMASH 将从 link 元素的 href 属性获得另一个 URL，并解析那个 URL，以获得用户事件和照片信息的机器可读的表示。由于这些表示在其它数据中包含了软件很容易识别的日期和位置，因此 MissMASH 可以使用这些备选表示来同时呈现日历和照片数据。
为了更好地说明，再想象一下，假设 Citibank 在用户的帐户 URL 上使用内容协商。那么， MissMASH 可以与 Citibank 服务器进行协商，以获取所支持的不同格式，例如 Atom 提要或 Quicken Interchange Format （参见 参考资料）。
现在，我们已经有了在 MissMASH 中显示外部个人数据源所需的几乎所有信息。当然，为了让 MissMASH 以这种方式使用并行 Web，它必须理解它所得到的机器可读的表示的结构和语义。如果 MissMASH 从 Google Calendar 收到 iCal 数据，从 Flickr 收到 Atom 提要，并且从 Citibank 收到 Quicken Interchange Format 数据，那么它必须理解如何解析和解释所有这三种机器可读的格式，以便合并信息。并行 Web 技术本身并不能帮助解决这个问题。相反，并行 Web 的关键优点是用户不必通过访问晦涩的源数据服务的配置网页，来找出 MissMASH 支持的某一种数据格式的 URL。虽然 MissMASH 必须重点支持少数几种不同的格式，但是也比为了检索数据，而要求 MissMASH 同时理解各种数据格式和各种特定于应用程序的、为人设计的服务要好得多。
本系列以后的文章将考察用于创建有意义的 Web 的一些技术，该 Web 将减轻数据使用者理解多种机器可读格式的负担。
评估
与 Web 上大多数事情一样，在本节中，我们关于评估类别的结论也不会是一刀切的。没有非白即黑的答案，正因为如此，才会有多种相互竞争、相互补充的技术共存。然而，我们将尽量帮助您理解评估结果背后的推理，从而让您理解为了让机器与人在 Web 上愉快共存，需要哪些东西。在这些评估中，我们使用以下标记：
-
 —— 该技术满足本评估标准的大多数或全部需求。
-
 —— 该技术满足本评估标准的某些需求，但是有一些重大的缺点。
-
 —— 该技术不能满足本评估标准的需求。
权威性的数据
我们提到的两种并行 Web 技术都涉及到一个数据使用者，这个数据使用者获取最初为人设计的内容的备选表示。当使用 link 元素时，人类可读格式与机器可读格式之间的链接包含在 HTML 页面本身之中。因此，这种关系是内容创建者所认可的，我们可以相信，备选表示是通过 HTML 网页向人们展示的数据的真实表示。当使用内容协商时，由控制内容的 Web 服务器来选择和返回备选表示，因此我们同样可以确信，机器可读的数据与面向人的内容的语义是一致的。
由于并行 Web 技术并不强制要求备选数据表示有特定的格式，因此理论上讲，与最初对人友好的网页相比，这些技术不仅可以提供等价的机器可读数据，而且还可以使这些数据在内容上和语义上更加丰富。然而，我们必须指出，大多数在线服务使用该技术链接到 Atom 提要，而 Atom 提要 常常只以机器可读格式捕捉少量初始数据。例如，银行交易的一个 Atom 提要可能以机器可读的格式捕捉交易的日期、地点和标题，而（并行 Web 上未广泛使用的）Quicken Interchange Format 则包含更丰富的语义数据，例如帐号、交易类型和交易数量。
我们的评估：并行 Web 提供非常权威的良好的数据，但是在通常使用中，并没有提供完全表示出面向人的权威内容的机器可读的数据。
表现性和可扩展性
就表现性和可扩展性而言，并行 Web 技术做得并不是很好。这些技术是通过灵活地允许多种备选内容表示并存的方式来实现可扩展性的。然而，为了达到这个目的，必须维护很多 URL（在使用 link 元素的情况下）或者很多服务器端文档及其相应的类型映射（在使用内容协商的情况下）。提供这些技术的发布者还必须维护从底层初始数据源（通常是关系数据库中的数据）生成每种备选表示的代码。
然而，优点同样也是很明显的。由于并行 Web 技术不强制要求特定的备选表示，因此实现者可以自由选择一种本身具有很好的可扩展性和表现性的表示。不过，在实际情况中，目前在 Internet 上与并行 Web 技术一起使用的事实上的格式并没有为新数据格式的扩展提供很多的灵活性，也没有提供更丰富的语义。
我们的评估：并行 Web 在容纳新数据和新表示方面足够灵活，但是现有的实现还不能伸缩自如，现有的数据格式可扩展性并不是特别好。
不要重复自己
根据 "不要重复自己"（DRY）的原则，如果必须为数据创建人类可读和机器可读的版本，那么应该不需要分别维护两种数据格式。虽然并行 Web 技术较幼稚的实现会导致在 Web 服务器上仍然需要维护包含重复信息的多个文件，但是现实中的实现还是从一个底层数据源（通常是关系数据库）生成不同的表示。
我们的评估：虽然必须维护用于生成不同数据格式的算法，但是实际的数据只需表示一次。
数据局部性
这是我们对并行 Web 有微词的一个地方。在使用 link 元素的情况下，相关信息的对人友好版本与机器可读版本分开放在两个不同的资源位置。在使用内容协商的情况下，虽然两种版本共用同一个 URL，但是对人友好的内容与机器可读的内容仍然是完全分开地被接收的。在这两种情况下，通常都难于合并和匹配这两种截然不同的格式（例如 HTML 与 Quicken Interchange Format）中的数据。因此无法确定哪块机器可读数据与哪些面向人的可视化元素是对应的。所以，人或软件也就不能在其它地方选取一小部分内容（不管是人类可读还是机器可读内容）进行重用。
我们的评估：无论如何，并行 Web 不具备数据局部性。
现有内容的保真度
任何已经使用内容协商或 link 元素的现有 Web 站点，都是以一种与本文描述的并行 Web 技术一致的方式使用这些技术的。另一方面，知道并行 Web 的软件不会为网页在已有的基础上附加更多的意义，因此不必担心会给现有内容带来不正确的语义。
我们的评估： 并行 Web 是一项已经在使用的技术，采用这种技术并不会威胁当前 Web 站点的意义。
标准遵从性
由于其内在本质，并行 Web 技术是遵从标准的。link 元素和内容协商都是在 HTML 和 HTTP 规范中分别指定的，它们已经被世界各地的很多开发社区接受。同样值得注意的是 MIME 类型在 IANA 的标准化，以及目前 Web 上广泛使用的很多格式的一致性。然而，除了指定的 MIME 类型外，开发人员对关于被链接资源的内容的更具体的信息，例如关于 Atom 提要中的提要条目的内容的更多信息，其暴露方式还没有得到广泛的标准化。
我们的评估： 开发人员和实现者可以确信，并行 Web 很好地受到了已被接受的标准的支撑。
工具
并行 Web 通过大量使用工具使它本身对开发人员更有吸引力。Internet 上充满了直接或间接支持并行 Web 的工具，使它非常适合更广泛的部署。正如您看到的那样，Apache HTTP 服务器包含对内容协商的广泛支持。所有其它主流 Web 服务器包也是如此。HTML 编辑器软件支持创建 link 元素，Web 浏览器和 blog 阅读软件也为并行 Web 提供了支持。此外，由于每种格式各有所长，并且有支持它们的社区，因此 Internet 上总是有很多语言的和许可的工具包，这些工具包在应用程序开发期间负责处理很多细节。
我们的评估： 并行 Web 存在已经有一段时间了，有很多成熟的工具在产生或者使用并行 Web。
整体复杂性
通常，采用并行 Web 技术的整体复杂性属于中等。并行 Web 技术的概念非常简单，由于它们的标准遵从性和大量可用的工具，实现这些技术并不难。此外，将机器可读信息与人类可读版本的规范分开也有一些优点：
- 设计者不必同时维护数据和表示。
- 便于对内容进行优化，以满足目标消费者的需要。
与此同时，我们也接触到一些领域，在这些领域中，并行 Web 比其它方法更复杂。使用 link 元素时，需要为不同数据表示维护不同的 URL。在如今的环境中，一个 "404 Not Found" 错误就可以使您与竞争对手拉开距离，因此维护这许多活动 URL 会是一个沉重的负担。内容协商本身要求维护中等复杂的服务器端配置。由于两种技术都支持相同数据的多种表示，因此必须编写和维护用于从核心数据生成这些表示的代码。
总体评估：目前，并行 Web 已经被广泛地理解和使用，但是随着时间的推移，它同时也要求进行大量的维护。
结束语
并行 Web 一直以来都被用于改善人类在万维网上的体验，但是最近，它也被大量地用于增强软件使用 Web 上的数据的能力。并行 Web 承认人和机器有不同的内容需求，并允许用于人的表示与用于机器的表示并存，从而区分这些不同的需求。它并行地维护那些不同的表示，但是为了达到这个目的，要么需要使用（面向人的）HTML link 元素将很多 URL 链接在一起，要么需要使用内容协商屏蔽相同 URL 背后的多种表示。目前，构成并行 Web 的技术已经被广泛提供和使用，并且在可预见的将来，还将继续被使用。
尽管如此，正如您在本文中看到的那样，这两种方法都有缺点，这些缺点使它们目前还只能在语义很少的范围内使用。当使用 link 元素时，需要维护多个 URL，并且需要多个 HTTP 请求才能得到机器可读的数据。内容协商则将不同表示隐藏在一个 URL 之后，阻碍了内容的人类视图与机器视图的统一。而且，机器可读表示之间缺乏一致性，目前惟一常用的机器可读表示 Atom 缺乏可扩展性，由于这些原因，对于所产生和使用的数据不能保证恒为结构化数据的 MissMASH，还不能采用并行 Web。
在本系列剩下的文章中，我们将考察致力于实现对人和机器都有意义的 Web，同时不必维护并行 Web 的两条（或更多）主线的技术。这些技术从一个 HTML 网页开始，从页面的内容导出语义。因此，它们都具有不需要为不同表示使用不同 URL，以及在相同载荷中可同时包含面向人和机器的内容的优点。但是可以看到，这些技术在方法上有本质上的区别，它们各有其优缺点，对此我们将加以评估。
在接下来的文章中，我们将考察算法方法，在这种方法中，第三方使用结构和启发式技术从为人设计的 HTML 网页导出机器可读的语义。
参考资料 学习
获得产品和技术
讨论
作者简介  | | | Lee Feigenbaum 是位于马萨诸塞州 Cambridge 的 IBM Internet 技术团队的顾问软件工程师。他当前的工作主要集中在研究和开发战略和软件上，以便在企业内利用语义 Web 技术。过去的研究和开发主题包括即时消息传递软件、结构化注释系统和 DHTML 客户机运行时。他定期在他的博客 TechnicaLee Speaking 中撰写有关语义 Web 和其他主题的文章。 |
| | | Elias Torres 是位于 Cambridge, MA 的 CIO 组织中的 IBM WebAhead 实验室的高级软件工程师。他现在主要研究的领域包括语义 Web、Web 2.0 和社会性软件。在 IBM，他曾经开发、部署和宣讲过基于开放源码软件的两个主要合作服务，即 Blog Central 和 Wiki Central。他是 Apache Software Foundation 开放源码项目的积极提交者，并且他还参与了 W3C 中语义 Web 标准的开发。他的博客是 http://torrez.us。 |
对本文的评价
| 
