在浏览器能处理下一代的 XHTML 之前先从这个更丰富的内容结构中获利
XHTML 2 规范尚未完成，但是它相对 XHTML 1 已经具有了许多优势，其中包括更丰富的结构特性，这使得 XHTML 2 作为一种编辑格式将比其前任能更好地充当单一资源发布系统的中心模式。执行大型或小型发布的人们现在就可以开始使用 XHTML 2 的新特性，而不必等待浏览器提供它的新用户接口特性的支持。
大约在一年以前，一个行业标准小组要我介绍一下 XHTML2 可能对发布者有哪些用处。我不知道它是否具有实用性，但是他们愿意提供去纽约的费用，因此我决定去调查一下。
我所做的调查并不需要花大力气。XHTML 2 在 XHTML 的基础上添加更丰富的结构，使之成为一种可用于创建和存储内容的格式，而并不单单是能够把内容传递给浏览器。当我说 XHTML 2 已经有用时，我稍微夸张了一点；许多店铺针对这个尚未完成的标准都有一些非常明智的政策，而且 XHTML 2 还仍然处于工作草案（Working Draft）的阶段（有关更多信息，请参阅 参考资料）。与几乎所有的 HTML 相关标准都有所不同，XHTML 2 能够在知名的浏览器对它提供支持之前提供大量有价值的东西，原因在于，它更可能以更丰富和复杂的结构来存储内容，而不会过多地偏离为人所熟悉的 HTML 元素和属性。 XHTML 的现状：我们进展到哪了
W3C XHTML 1.0 标准创建了一种 XML 版本的 HTML。当浏览器并不过分讲究 Web 页面是否为格式良好的 XML 时，Web 站点设计人员已经厌倦于针对 Firefox 使用一套方法而针对 Microsoft™ Internet Explorer 又使用另一套方法，他们在标准中看到了更多的价值。许多开源 CSS 集合（如 Open Web Design 和 Open Source Web Design，有关这两者的链接，请参阅 参考资料）的样式表使用 XHTML 1 示例文件用于演示目的，我曾听说一些几乎不知道格式良好 是什么的 Web 设计人员很骄傲地宣称他们的站点是 XHTML 构成的。随着 Internet Explorer 和 Firefox 支持的 CSS 特性越来越多，这些 Web 设计人员把更多设计技巧加入到 CSS 样式表中，把更简单更直接（以及更易于重复使用）的 XHTML 留在基本文档中。
XHTML 1.1（请参阅 参考资料）并没有加入新特性，但是却把 XHTML 分成了模块。其价值表现在两个方面。第一，如果我们发现某些模块存在价值，而其他模块没什么价值，则可以更方便地采用它的一个子集。比如说，无线应用论坛（Wireless Application Forum，WAP）完全有理由把基本的 XHTML 结构合并到其标准中，以便向移动电话传递内容，但是它并不想允许 WAP 文档合并一些用户接口特性，如在手机的小型屏幕中没多大用处的图像映射或者编辑模块功能。
对于 DTD 或者模式来说，模块化架构的另一个好处是可以更容易地插入用户应用程序所专有的新模块。与挑选现有模块的功能相结合，这种功能为发布行业带来了益处：致力于发布行业元数据的 PRISM 标准小组选择了 XHTML 1.1 的一个子集，然后加入了一些带有行业专有词汇的新模块，以便更容易地通过发布工作流来跟踪内容。（有关 PRISM 的更多信息，请参阅 参考资料。）
您可以把 XHTML 1.1 的开发比作清理地下室：您可能不用扔掉太多东西，通过更好地进行组织，可以更方便地使用现有物品，甚至可以腾出空间来搭建一个工作台，在上面做些新东西。
自从 2001 年 5 月开始，XHTML 1.1 就成为了一个标准（或者，按照 W3C 的说法，一个推荐标准）。XHTML 2.0 最近的进展是 2006 年 7 月发布的一个新工作草案（Working Draft）。虽然其最终形成还要必须经过几个阶段，但是可以使用 RELAX NG 模式（请参阅 参考资料 获得该链接）使我们现在就能够创建和使用 XHTML 2 文档，以便在该规范成为推荐标准时可以快速地转到 XHTML。简单的 XSLT 样式表将把这些文件转换成 XHTML 1 以供浏览器显示，或者您也可以使用如今含有 XHTML 2 Working Draft（请参阅 参考资料）的 CSS 样式表在浏览器（就目前来说，Firefox 应该效果更好）中显示这些文档。 XHTML 2：有什么新特性？
XHTML 2 保留了 XHTML 1 中清除现有语法的功能使它更加简洁，同时还加入了一些新特性。它加入了对 XForms 的支持，XForms 是表单的更加完善的继承者，它在 HTML 中已应用了十年以上。XHTML 2 中还包括 XML 事件（XML Events），它可以让我们识别由某些用户接口操作所触发的事件，因而减少了使用 JavaScript 或者 ASP 编写脚本的需要。这些特性会是有趣的，尤其是当主要浏览器对它们提供支持以后，但是其他的特性即使在浏览器支持 XHTML 之前对发布人而言也会更加有趣： 一个更丰富、可重用性更好的结构 设备独立性更好、更易访问、语义更完善 更易于添加元数据
#p# 更丰富的结构
许多需要在 XML 中存储内容的发布者都知道使用现有的标准模式（我指的是 W3C Schema、RELAX NG 模式或者 DTD）要比自己从头创建一个更好。他们看了 DocBook 后发现太复杂了，他们看了 HTML 或 XHTML 1 之后又发现太简单了。对于许多发布者来说，XHTML 2 很好地平衡了 DocBook 的丰富性和 XHTML 1 的简单性，这种平衡使之成为存储内容的一种极佳的格式，不论内容是否需要被转换成其他的格式以供在各种媒体中传递。
清单 1 包含了一个示例 XHTML 1 文件，并以缩进格式表示了该文件的结构。
清单 1. XHTML 1 文件的结构
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>My Web page</title>
</head>
<body>
<h1>My Web Page</h1>
<p>Here is my Web page.</p>
<h2>Section 1 of my Web page</h2>
<p>Here is section 1 my Web page.</p>
<h3>Section 1.1 of my Web page</h3>
<p>Here is a subsection of my Web page.</p>
<h2>Section 2 of my Web page</h2>
<p>Here is section 2 of my Web page.</p>
</body>
</html>
我们可以看到 body 元素内部并没有太多的缩进格式，这是因为该元素中没有多少结构。这个文档的树形表示会显示出一个带有许多子元素而没有孙子元素的 body 元素，段落 “Here is a subsection of my Web page” 将作为主 h1 标题 “My Web Page” 的兄弟元素显示出来。标记中只有一个地方指示出这个段落是一个子段的一部分：它前面最近的题头，h3，比前一个题头的数字大。容器元素不会把任何作为标题的题头与其内容组合在一起，除非让 body 元素把 h1 header 题头与 Web 页面其余可显示的内容封装在一起。我们可以使用一个 div 元素把每个题头/内容（header/content）组合封装在一起，不过 div 元素与 span 元素一样是一种相当通用的分组元素。它可以用于许多目的，比如说指示一些特定的段落形成一个菜单或者一个侧栏或者 Web 页面中的另一个可视表示元素，因此我们不能假定其表示指示内容的一个结构单元。
XHTML 2 中的新增的 section 和 h 元素结合在一起能使我们创建一个更丰富的结构，从而使内容更易于重用。清单 2 演示了与 清单 1 中的 body 元素等价的 XHTML 2 body 元素。
清单 2. XHTML 2 body 元素
<body>
<section>
<h>My Web Page</h>
<p>Here is my Web page.</p>
<section>
<h>Section 1 of my Web page</h>
<p>Here is section 1 my Web page.</p>
<section>
<h>Section 1.1 of my Web page</h>
<p>Here is a subsection of my Web page.</p>
</section>
</section>
<section>
<h>Section 2 of my Web page</h>
<p>Here is section 2 of my Web page.</p>
</section>
</section>
</body>
在这一版本的代码中，“Here is a subsection” 段落是第一个 section 元素的曾孙元素，这个 section 元素中的 “My Web Page” h 元素显示了其主标题 — 正应该如此！
这种丰富结构的优势之一（也是 XHTML 2 比 XHTML 1 更适合充当单源发布系统的中心格式的一个关键原因）就是更容易进行流处理。如果您需要处理大量的输入而无法在处理之前把这些输入加载到内存中 — 比如说，如果要为 CD-ROM 准备内容 — 处理会更容易计算出每个 sectiong 元素在 XHTML 2 文档中的哪里结束。比如说，假设我们想要调出所有标题中含有单词 “Beagle” 的部分。找到这些标题足够简单，但是要在 XHTML 1 中决定 section 在哪里结束就不是一般的困难了。对这种 XHTML 的处理是否使用了基于流的接口、Xquery 或者 XSLT，清楚地定义 section 的结束位置可以使提取简单很多。
现在，设想您提取这些 section 因为您将把他们加入到关于 beagle 的新发布中，而且调出的每一个 section 都有一个 h3 元素作为其题头。标有数字的 XHTML 1 题头，如 h3，在 XHTML 2 中仍然合法，但是如果新的发布将使用这些元素作为一个特别章节中的主 section，或者子 section 会怎样呢？您需要回去并把 h3 元素修改为 h2 元素或者 h4 元素，或者任何能在新上下文中识别自己角色的元素。如果它们在原始文档中是 XHTML 2 的 h 元素，通过每个 section 祖先元素的数字指示出它们角色的等级（比如说，清单 2 中的 section 1.1 h 元素有三个 section 头祖先元素，而 “My Web Page” h 元素只有一个），那么您可以把它们插入未经修改的新文档中，通过新文档的 section 元素的嵌套排列指示出其角色。CSS、XSLT 和其他 XML 处理工具和标准都提供了一种根据嵌套层次处理同名元素的方法，因此我们不会错过作为 XHTML 1 题头一部分的数字。我们考虑有 h2 和 h3 元素但是没有 h1 元素，或者有h1 和 h3 元素但是没有 h2 元素的 (X)HTML 文档的数目时，很明显太多人不会使用它们指示合适的等级。
在 XHTML 2 中，p 元素中还可以有更多的结构。我想介绍一些语句中的示例代码，比如说下面这个：
print "Hello? World?";
如果我想要在示例代码之后继续该语句，XHTML 1 会强制我把语句分成两部分放在两个不同的 p 元素中，不过从语义上说它们位于同一个语句中。XHTML 2 让我们把示例代码、无序列表和编号列表和许多其他块元素放置在一个 p 元素中，让我们的标记能更准确地反映出文档的结构。
从表示标记到结构型标记还要一小步，把 hr 元素重命名为 separator。HTML 工作小组（HTML Working Group）发现其原始名称（代表 horizontal rule）经常落入结构型标记和表示标记之间的灰色区域。他们收到了一些使用亚洲国家语言的用户发出的 vertical rule 请求，他们看到许多水平分离器并不是真正的规则（HTML 工作小组的主席 Steven Pemberton 作了一个陈述，其中指出了 James Joyce 的 Ulysses 中的几个不同的变种；请参阅 参考资料 以获得到该陈述的链接）。这使得他们把 hr 元素重命名为能更准确地返回其使用的名称并在陈述中允许了更强的灵活性。
#p# 设备独立性更好、更易访问、语义更完善
这三个目标实际上有相互重叠的地方。对于不用在一个平台上传递的 Web 页面和视力减弱的用户能方便地理解的 Web 页面来说，文本语音翻译器读出 Web 页面中的内容仍然具有意义。XHTML 2 工作草案（XHTML 2 Working Draft）中提到：
各种新设备出现在网络上，如电话、PDA、写字板、电视等等，这意味着需要有一种设计，允许我们创作一次然后在不同的设备上以不同的方式呈现，而不是为每种类型的设备都创作一种新版本的文档。
发布者不需要从未来考虑其价值。设备独立使它们中的很多在 XML 发明之前应用于 SGML，因为它让这些设备以打印的方式，在 Web 页面上以及在 CD-ROM 上发布相同的内容，只要该内容的编辑版本中存储有足够的结构和语义信息，从而使自动例程把它转换成各自的格式。我记得十一年之前当我们的竞争者要把内容的编辑版本存储为 HTML 时，我的前老板的办公室中充斥着窃笑声；使用 XHTML 2 就不再是一个疯狂的想法了。
如果 XHTML 2 元素中已有的语义对你来说还不够的话，新加入的 role 属性（可以被加入到任何元素中）可以告诉你元素更多的用途。XHTML 2 规范为这个属性指定了九个可能的值：banner、note、contentinfo、search、definition、secondary、main、seealso 和 navigation。角色值，如 banner 和 navigation，显然更加面向表示，但是对于 definition 和 note 之类的值，其中的语义在为多媒体准备内容的发布环境中更具实用性。您甚至还可以构造自己的 role 值，只要它们处于自己的名称空间就即可。 更易于添加元数据
W3C RDF 标准让我们把元数据指派给任何能够使用 URL 识别的内容。这一操作的标准 RDF/XML 语法出现于 1999 年，它的复杂和困难程度吓退了许多人。通过使用已有的 HTML 属性和加入一些新属性，XHTML 2 让我们使用新的、更简单的 RDFa 语法添加有关文档和文档组件的元数据（可以使用一个 about 属性识别它们）。清单 3 中的一些例子中，span 元素存储了嵌入主谓宾三重结构所需的附加信息（当作宾语 ID-attribute name-attribute 值三重结构可能会更容易），用于表示 RDF 元数据。
清单 3. 使用 span 元素编码元数据
<section>
<span property="dc:subject" content="recipe"/>
<span property="fb:workflowStage" content="3a"/>
<h><span property="dc:title">
Carrion, My Wayward Son
</span></h>
<p><span property="dc:date" content="2007-05-15" datatype="xs:date>
May 15, 2007
</span></p>
</section>
</blockcode>
</section>
因为 清单 3 中的 RDFa 标记并没有使用任何 about 属性来命名主语，因此 RDFa 处理器会假定文档本身就是各个三重结构的主语，这正是我们所希望的 — 它们是关于文档本身的元数据。
假设前缀 dc 声明表示 Dublin Core 名称空间 http://purl.org/dc/elements/1.1/，fb 表示虚拟 FooBar Company 的 http://www.foobarco.com/ns/vocab# 名称空间，清单 3 中的 RDFa 标记使我们可以在 RDF triples 的数据库中提取和加载如下语句： 这个文档拥有一个 Dublin Core 主语 “recipe”。 这个文档的 workflowStage 值（创建该文档的公司的自定义的元数据）为 “3a”。 这个文档的 Dublin Core 标题为 “Carrion, My Wayward Son”。对于这个语句来说，元数据值，或者该 triple 的宾语，是当前 Web 页面的一部分，并且没有像其他的 span 元素一样存储在 content 属性中。不需指定单独的宾语并且让文档本身充当主语，我们在文档中添加了一个实用的三重元数据，其中 span 元素只有一个属性。 这个文档的发日期是 2007 年 5 月 15 日。存储的确切值为 ISO 8601 标准格式的 2007-05-15。甚至还包含键入信息：为 W3C Schema 日期数据类型。
Semantic Web 的梦想主要是允许把 Web 页面数据既当做内容发布以供人们阅读，同时又当做数据以供程序员阅读，从数据库算起，比如 清单 3 中所演示的 dc:title 的例子。fb:workflowStage 例子演示了 RDFa 的另外一个优点：我们可以真正地在 XHTML 2 文档中添加任意的元数据，专门用于您自己的店铺，这使得文档更易于跟踪和重用。 现在就开始使用 XHTML 2
我们仍然需要等待一段时间，然后才能使用 XHTML 2m 中较新的用户接口特性，如 XML 事件（XML Event），但是我们现在可以实验 XHTML 2 中的新结构特性。作为一个尚未完成的规范，XHTML 2 仍然是一个进展中的目标，但是其进展很慢。模式和 CSS 样式表当前已经可用，我们可以尝试使用它并考虑它可能会给我们的操作带来哪些好处。事实上，我正是使用它撰写了这篇文章，使用 nXML 模式中的 Emacs（请参阅 参考资料）驱动 XHTML 2 的 RELAX NG 模式中的上下文敏感的 XML 编辑。在我提交这篇文章之前，我已经使用一个简单的 XSLT 样式表把它转换为符合developerWorks DTD 的格式。到 XHTML 2 成为标准推荐标准的时候，我计划让它全速运行。