XML和相关规范：领会Alphabet Soup

现在你已经对XML有了基本的理解，接下来站在高处看一看各种与XML相关的缩略词以及它们的意义是很有用的。XML涉及的范围很广，所以我们要学习的东西还很多。

当前用于访问XML文档的API，不管访问模式是连续的还是随机的，这些API都分别属于SAX和DOM。为了确保XML文档的有效性而作的规范说明就是DTD（一种原始的机制，作为XML规范的一部分一起定义）和各种模式标准建议（一种较新的机制，使用XML语法来描述有效性确认标准）。

其他即将完成的未来标准包括XSL标准——一种用于建立XML文档转换（例如转换成HTML或其他XML）以及规定如何进行转换的机制。该标准中关于转换的部分——XSLT (+XPATH)已经完成，并且在本教程中也对此作了讲述。另一个即将完成的是XML链接语言规范（XML Linking），该规范允许使用XML之间的链接。

上面提到的都是你希望熟悉的一些主要的倡议。本节还将讲述大量其他有趣的建议，包括看上去类似HTML的标准XHTML，还有为描述XML文档所包含的信息而推出的   RDF。还有用于扩展XML功能性的标准，例如Xlink和Xpoint。

最后，还有很多关于XML的有趣的标准以及标准建议，包括同步多媒体集成语言 （Synchronized Multimedia Integration Language，SMIL）、数学标记语言（Mathematical Markup Language，MathML）、可缩放矢量图（Scalable Vector Graphics ，SVG），以及DrawML，还有很多的电子商务标准。

本节剩下的部分将对这些  作更详细的描述。为了直观起见，我们将这些内容分为一些部分：

·   基本标准

·   模式标准

·   链接和表示标准

·   知识标准

·   建立在XML上的标准

首先请将这些术语过目一下，以便知道这里讲了些什么，而且最好将本文的一份拷贝保留在身边，以便以后在阅读中发现了这些术语时可以参考本文。很快，你就会将这些术语记在脑海中，并且至少会与XML“有些交情”。

基本标准

有些基本的标准你需要熟悉它们。这些标准中相当多的一部分都是通过对XML的讨论而得出的。

SAX

简单API for XML（SAX）

这种API实际上是XML-DEV的mailing list的同道们努力协作的结晶，而不是W3C的成果。这里之所以要提到SAX，是因为它与W3C建议有在“根本上”相同的特性。

你也可以把这种标准看作是XML的“连续访问”协议。这是一种快速执行机制，例如，你可以通过这种机制来读或者写服务器上的XML数据。也可以将其称为是一种事件驱动的协议，因为这种技术是用一个SAX解析器来注册你的句柄，此后，只要解析器发现了一个新的XML标签（或者碰到了一个错误，或者想告诉你任何其他的事情），它就会调用回调函数。

想了解更多关于SAX协议的信息，参见Simple API for XML（网页地址：http://java.sun.com/webservices/docs/1.1/tutorial/doc/JAXPSAX.html#wp69937）

DOM

文档对象模型

文档对象模型协议将一个XML文档转变成程序中的一个对象集合。之后你就可以通过任何有效方式来操纵这个对象模型。这种机制也被称为是“随机访问”协议，意即你可以在任何时候访问数据的任何部分。你可以修改数据，删除数据，或者是插入新数据。要了解关于DOM规范的更多信息，参见Document Object Model（网页地址：http://java.sun.com/webservices/docs/1.1/tutorial/doc/JAXPDOM.html#wp66050）

JDOM和dom4j

虽然文档对象模型（DOM）为面向文档的处理提供了强大的支持，但是对于面向对象的简化，它并没有提供多少途径。有些Java开发者正在处理更多的面向数据的结构——而不是书、文章和其他成熟的文档，他们经常发现面向对象的API，如JDOM和

dom4j，使用起来更容易，而且更适合他们的要求。

在JDOM与dom4j之间作选择时，首先应该理解它们之间几点重大的不同之处：

·   JDOM是一种更干净、更小的API。如果需要重点考虑“编码方式（coding style）”，那么JDOM是一个很好的选择。

·   JDOM是一个Java Community Process^SM (JCP^SM)计划。一旦完成，它将是一种endorsed standard。

·   dom4j是一种更小、更快的实现，多年来一直都被广泛使用。

·   dom4j是一种基于factory（工厂）的实现。这使得修改复杂的、专用的应用变得更加容易。在撰写本文时，JDOM还没有使用一个factory来实例化解析器的实例（虽然这种标准已经有这方面的倾向）。所以，如果使用的是JDOM，那么你只能得到原始的解析器。（虽然对于大多数应用来说，这样是不错，但是如果你的应用是专用的，这就不大妥当了。）

要了解更多关于JDOM的信息，参见http://www.jdom.org/。

要了解更多关于dom4j的信息，参见http://dom4j.org/。

DTD

文档类型定义

DTD规范实际上是XML规范的一部分，而不是一个单独的实体。另一方面，它并不是必需的——你完全可以写一个没有DTD的文档。而且，很多模式标准（Schema Standards）建议都可以提供更灵活的DTD的替代品。所以，虽然DTD是一个独立的规范，我们还是将它放在这里进行讨论。

DTD指定了在XML文档中可以使用的标签类型，以及这些标签的合法的排列顺序。通过使用DTD，你就可以确保不会创建无效的XML结构。你还可以使用DTD来确保你正在读（或者在网络中发送）的XML结构确实有效。

不幸的是，如果要为一个复杂的文档指定一个DTD，指定DTD时要求能够防止所有的非法组合，只允许所有的合法组合，这是很困难的。所以构造一个DTD是一件有艺术性的事情。DTD可以放在文档的前头，作为序言（prolog）的一部分。它也可以作为一个单独的实体存在，或者还可以被拆分开，放在文档的序言和一个或多个附加实体之间。

不过，虽然DTD机制是第一个为规定文档格式而定义的方法，它却不是最后一个。后来大家又发明了一些新的模式规范。很快你就可以了解到这些模式规范了。

要了解更多信息，参见Creating a Document Type Definition (DTD)（网页地址：http://java.sun.com/webservices/docs/1.1/tutorial/doc/JAXPSAX8.html#wp64852）

命名空间（Namespace）

有了命名空间标准，你就可以使用两套或多套XML标签集，以模块化的方式编写XML文档。举个例子，假设你要创建一个基于XML的零部件清单，这个零部件清单要使用其他厂家（在线）提供的零部件的XML描述。你希望能够总计出各个子组件提供的“price”数据，然而你又希望可以将“”数据作为一个完整的结构显示出来。命名空间规范定义了一种机制，利用这种机制我们可以使所有名称都可以不会混淆地使用。

关于命名空间的最新消息，参见

http://www.w3.org/TR/REC-xml-names.

XSL

可扩展样式语言

XML标准规定的是如何标识数据，而不是如何显示数据。相反， HTML则只管如何显示内容，而不去管显示的到底是什么样的数据。XSL标准分为两部分，一部分是XSLT（转换标准，后面将对此作出介绍），还有一部分是XSL-FO（这部分是关于格式化对象，也叫流对象的）。XSL-FO让你可以在一个页面内定义多个区域，然后将它们链接在一起。当一个文本流要直接 进入该页面时，它首先充满页面的第一个区域，当第一个区域已满时，便“流”到下一个区域。这种对象通常用于时事通讯、目录和期刊出版物。

要阅读W3W关于XSL的最新文章，请访问：http://www.w3.org/TR/WD-xsl

XSLT (+XPATH)

可扩展样式语言转换标准

XSLT转换标准实质上是一种转换机制，通过它你就可以规定将XML标签转换成怎样的可以显示的格式——例如，转换成HTML。这样一来，不同的XSL格式就可以通过不同的方式用来显示相同的数据，以满足不同的用途。（XPATH标准是一种寻址机制，利用XPATH，你就可以在构造转换指令时找到你想要转换的XML结构的那一部分。）

要了解更多信息，参见XML Stylesheet Language for Transformations（网页地址：http://java.sun.com/webservices/docs/1.1/tutorial/doc/JAXPXSLT.html#wp68287）

模式标准

有了DTD，我们就可以确认比较简单的XML文档的结构是否有效，但是至此它也就黔驴技穷了。

DTD不能够约束元素的内容，也不能指定复杂的关系。例如，对于这样的规定：一个<book>的<heading>必须既有一个<title>，又有一个<author>，而一个<chapter>的<heading>只需要一个<title>，使用DTD是无法办到的。在DTD中，你只能一次性地指定<heading>元素的结构。

之所以存在这样的问题，是由于DTD规范并不是相对于层次性的。例如，对于一个包含了几个“解析字符数据”（PCDATA）元素的邮件地址来说，对应的DTD看上去大概是这样的：

<!ELEMENT mailAddress (name, address, zipcode)>

<!ELEMENT name (#PCDATA)>

<!ELEMENT address (#PCDATA)>

<!ELEMENT zipcode (#PCDATA)> 

正如你可以看到的那样，这种规范是线性的。这样就迫使你对于类似的具有不同设置的元素，使用新的名称。所以，如果你想将另一个“name”元素添加到某个DTD中，并且该DTD已经包含了<firstname>、<middleInitial>和<lastName>这几个元素，那么你就不得不换用其他的标识符了。如果你还是简单地称它为“name”，那么就必然会与已经定义好了的要在<mailAddress>

中使用的<name>元素相冲突。

DTD由于不具有层次性而引起的另一个问题是，我们常常搞不清有些注释要解释的到底是什么。例如，一个位于文档顶部形如<!--Address used for mailing via the postal system -->的注释，将应用到组成一个邮件地址的所有元素上。而对于一个形如<-- Addressee -->的注释，就只能应用到name组件了。另一方面，一个形如<!-- A 5-digit string -->的注释将特定地应用到zipcode元素的#PCDATA部分，用来描述合法的格式。最后，你不能用DTD来规定字段的合法格式，例如限制zipcode字段为5-digit（或者5和4）。

最后，DTD使用的语法与XML有很大的差别，所以不能使用标准的XML解析器来处理DTD。这就意味着你不能将DTD读入DOM中，在DOM中进行修改，然后再将其写回。

为了补救这些缺陷，人们已经推出了许多更类似于数据库的、层次性的规定了合法标准的“模式”的建议。主要的建议有：

XML Schema

这是一个很大、很复杂的标准，可分为两部分。一部分规定了结构关系。（这也是最大、最复杂的部分），另一部分规定了一些用于确认XML元素的内容的机制，它为每个元素都指定一个（常见的）数据类型。好消息是，应用于结构的XML Shema让你可以为元素指定你能想到的所有关系。不好的消息是，这种建议实现起来要做大量的工作，不过只需经过很短的学习就可以使用它了。大部分该建议的替代品虽然也提供了更简单的结构定义，但是需要结合XML Schema数据类型才行。

要了解更多关于XML Schema的信息，参见W3C规范XML Schema（结构）和XML Schema（数据类型），其他信息还可以通过访问http://www.w3c.org/XML/Schema获得。

RELAX NG

XML的正规语言描述

这种标准比起XML Structure Schema来更简单，它是在OASIS（结构化信息标准促进组织）的支持下正要出现的一种标准。RELAX NG使用正规表达式的模式来表达对结构关系的约束，并且使用XML Schema数据类型指定机制来表达对内容的约束。这种标准还使用XML语法，并且在RELAX中包含了一个DTD。（“NG”代表“Next Generation”，即“下一代”。这是一种更新的结合了TREX的RELAX模式机制）

要了解更多关于RELAX NG的信息，参见http://www.oasis-open.org/committees/relax-ng/

TREX

XML的正规表达式树s

这种标准通过描述XML文档的结构和内容的一种模式，从而为表达确认标准提供了一条途径。现在，TREX是RELAX NG规范的一部分。

要了解更多关于TREX的信息，参见http://www.thaiopensource.com/trex/。

SOX

用于面向对象XML的模式

SOX是一种模式建议，包括可扩展数据类型、命名空间以及嵌入式文档。

要了解更多关于SOX的信息，参见http://www.w3.org/TR/NOTE-SOX

Schematron

用于面向对象XML的模式

一种基于断言的模式机制，允许进行先进的确认。

要了解更多关于Schematron 确认机制的信息，参见 http://www.ascc.net/xml/resource/schematron/schematron.html.

链接和表示标准

可以证明，HTML具有的两个最大的优点，一个是允许在文档之间使用链接，一个是允许创建简单格式化的文档（而且，最终也可以创建复杂格式化的文档）。下面的标准都力图在XML中保留HTML的这些优点，同时还添加了一些新的功能。

XML链接

这些规范提供了各种各样的有力的链接机制，并且肯定会对XML文档的用法产生很大的冲击。

XLink

Xlink协议是一种用于处理XML文档之间的规范。这种规范允许使用一些相当先进的链接，包括双程链接、多文档链接、“展开”链接（单击这样的链接时，链接的目标信息将在页面内显示出来，而不会新开一个页面代替当前页面），以及通过第三方的、独立的文档创建的两个文档之间的链接，还有一些直接链接（通过它你可以指向一个“地址簿”，而不是直接指向目标文档——对地址簿的更新将自动引起对所有使用该地址簿的链接的更新。）

XML Base

这种标准为一些XML文档定义了一中特征，这些XML文档定义了一个“基”地址，当计算文档中指定的一个相对地址时，就要用到这个基地址。（例如，某个简单的文件名就可以在基地址目录下找到。）

XPointer

通常来讲，Xlink规范的目标是找到一个文档或者使用了该文档ID的文档片段。而Xpointer规范则定义了一些机制，这些机制的目标是“XML文档内部结构的寻址”，并不要求文档的作者已经定义了那个片段的ID。该规范提供了“对XML文档中的元素、字符串和其他任何部分的引用，不管它们（元素、字符串等）是否有明确的ID属性。”

要了解更多关于XML链接标准的信息，参见http://www.w3.org/XML/Linking.

XHTML

XHTML规范是一种制造与HTML文档的外观和行为都相象的XML文档的方法。既然XML文档可以包含任何你自己定义的标签，那么为什么不定义一套看上去像是HTML的标签呢？这就是XHTML规范无时不想的事情。这种规范的成果就是一种既可以在浏览器上显示，又可以作为XML数据来对待的文档。这种数据也许不像“纯”XML那样易于识别，操纵起来比标准HTML却要简单得多，因为

XML规范更具有规则性和一致性。

例如，在一个格式良好的XML文档中的每个标签都必须要么有一个与之对应的结束标签，要么必须以/>作为结束。所以你看到的要么是<p>...</p>，要么是<p/>，但是你决不会看到一个单独的<p>。这样要求的结果是，你永远也不会碰到像在HTML中碰到的那样怪异的情况，例如，在HTML中，一个<dt>标签可能以</DT>结束，可能以<DT>结束，也可能以<dd>结束，后者以</dl>结束。所以，编写代码就容易得多了。

XHTML规范实际上是对HTML4.0的一种改进，然后放在XML中，要了解最近的信息，参见http://www.w3.org/TR/xhtml1.

知识标准

如果你再往后看5到6年，并想象一下那时Web上的信息将开始转变成一个巨大的知识库（“语义网”）。要了解关于语义网的最新动态，请访问：http://www.w3.org/2001/sw/。

同时，你可能还想知道下面的一些基本的标准：

RDF

资源描述框架

RDF是一种用于定义元数据的标准（元数据是指用于描述某个特定数据是什么，以及规定如何使用这种数据项的信息）。例如，如果与XHTML规范或者HTML页面一起使用，RDF可用于描述页面的内容。例如，如果你的浏览器你的一些ID信息（如FIRSTNAME、LASTNAME和 EMAIL），那么通过使用一个RDF描述就可以实现将数据传送给一个需要NAME 和 EMAILADDRESS的应用。想想吧：将来有那么一天，你不必在你访问的每一个Web站点上输入你的姓名和地址！

For the latest information on RDF, see 要了解关于RDF的最新信息，参见http://www.w3.org/TR/REC-rdf-syntax.

RDF Schema

RDF Schema允许规定一致性的规则和使用附加信息来描述在资源描述框架（RDF）中的语句该如何来解释。

要了解更多关于RDF Schema建议的信息，参见http://www.w3.org/TR/rdf-schema.

XTM

XML主题地图

在很多地方，比起RDF来XTM是一种更简单、更易于使用的知识表达（knowledge-representation），主题地图是一种值得我们关注的标准。到目前为止，RDF还是W3C关于知识表达的标准，但是主题地图很可能会在众多的知识表达标准中脱颖而出，成为“开发者的选择”。

要了解更多关于XML 主题地图的信息，参见http://www.topicmaps.org/xtm/index.html。要了解更多关于主题地图和Web的信息，参见http://www.topicmaps.org/。

基于XML的标准

下面介绍的标准和建议是基于XML的。既然XML基本上就是一种语言定义工具，所以这些规范就使用XML来为专用目的定义标准语言。

扩展的文档标准

这些标准定义了用于通过使用UML来产生极其复杂的文档的机制，这些复杂的文档包括书本、期刊、杂志和其他类似的文档。

SMIL

同步多媒体集成语言

SMIL是W3C推荐的标准，涉及到音频、视频和动画。SMIL还讲到了这些多媒体元素的同步回放这种难题。

要了解更多关于SMIL的信息，参见http://www.w3.org/TR/REC-smil.

MathML

数学标记语言

MathML是W3C推荐的标准，用于处理数学公式的表达问题。

要了解更多关于MathML的信息，参见http://www.w3.org/TR/REC-MathML.

SVG

可伸缩的矢量图

SVG是W3C的一个工作草案，它涉及到矢量图的表示问题。（矢量图是通过形如"draw a line (square, circle) from point xi to point m,n"这样的命令创建的，而不是将图编码成一系列的点。这种图像更易于伸缩，虽然这样做需要花费更多的处理时间。）

要了解更多关于SVG的信息，参见 http://www.w3.org/TR/WD-SVG.。

DrawML

绘图元语言

DrawML是W3C推出的注释（note），它涉及到用于技术说明的2D图像。同时还讲到了图像的更新和质量改善问题。

For more information on DrawML, see 要了解更多关于DrawML的信息，参见http://www.w3.org/TR/NOTE-drawml.

电子商务标准

这些标准的目标是在企业对企业（B2B）和企业对顾客（B2C）商业领域中使用XML。

ICE

信息和内容交换

ICE是一个由内容ICP和它们的订户使用的协议。它致力于"自动化传统出版和企业间关系中的信息（content）交换和重用"。
　　要进一步了解ICE，参见http://www.w3.org/TR/NOTE-ice。

ebXML

使用XML的电子商务

这种标准的目标是使用XML创建模块化的电子商务框架。ebXML是联合国（UN/CEFACT）和结构化信息系统促进组织（OASIS）共同计划的产物。

要了解更多关于ebXML的信息，参见 http://www.ebxml.org/.

cxml

商务XML

cXML是一个为不同购买者建立交互在线目录的RosettaNet（www.rosettanet.org）标准，也包含了处理购买订单、改变订单、状态更新和运输通知的机制。

要进一步了解cXML，参见http://corp.ariba.com/News/AribaArchive/cxml.htm.

CBL

通用业务库

CBL是一个由CommerceNet (www.commerce.net)维护的元素和属性定义库。

要进一步了解CBL和许多其它有关电子商务应用的信息，参见 http://www.commerce.net/projects/currentprojects/eco/wg/eCo_Framework_Specifications.html。

UBL

通用业务库

一种OASIS计划，目标是编译XML商用文档（订单，发票等）的标准库，这些XML商用文档是由XML Schema定义的。

要了解更多关于UBL的信息，参见http://www.oasis-open.org/committees/ubl.

小结

XML正要成为一种广泛采用的标准，被用在各种各样的应用领域。