截至目前为止，我们已经介绍了与XML相关的各种标准和技术。限于篇幅，对其中许多内容未能展开介绍，只是起到一个领路的作用，还需要各位读者在进行实际开发中，再参考更详细更权威的资料。在最后一章里，我们将简要介绍一下目前XML在各个领域的应用以及它的发展前景。一方面，XML的广泛应用和广阔前景恰恰是我们学习XML的最好理由；另一方面，我们曾经在各个章节中曾经反反复复地强调了XML的优点，而XML在实际应用中所发挥的巨大作用也正是对前面内容最好的证明和总结。

虽然人们对XML的某些技术标准尚有争议（也许这就是许多标准迟迟不能推出的原因），但是人们已经普遍认识到XML的作用和巨大潜力。作为SGML的简化子集，XML在SGML的应用领域依然有它的用武之地，如：文档、信息管理、出版系统等。另外，XML自身的特点决定了它在SGML的应用领域外拓展出了更为广阔的天地。

考察现在的XML应用，可以将它们分为以下几类。需要大家注意的是，这个分类并没有涵盖所有的XML应用，只是希望利用这个分类为读者提供一个XML应用的概况，而且随着时间的推移，XML的应用范围和方式必将会极大地拓展。

1. 设计置标语言

作为元置标语言，XML为用户提供了定义本行业本领域的置标语言的最好工具。目前这一应用的成功例子比比皆是，例如化学领域的CML，数学领域的MathML，移动通信领域的WML等。

2. 文件保值

XML良好的保值性和自描述性使它成为保存历史档案，如政府文件、公文、科学研究报告等的最佳选择。

3. 数据交换

数据交换无疑是XML最令人激动的应用。数据交换的核心问题是信息的标准化，主要解决信息的可理解性问题，包括人和机器对信息的理解。而且，更重要的是机器对信息的识别，并能根据数据进行自动处理。XML的出现，为信息的标准化提供了有力的工具。

由于不同的应用领域对数据的要求千差万别，因此要想制订一个放之四海而皆准的数据交换标准是不现实的，同时也是不必要的。最典型的作法是在同一应用领域制订一个标准，参与者按照这个标准组织数据，就可以进行数据交换。比如，IBM、UNISYS和其他合作伙伴定义的XMI（XML Metadata Interchange）是一个存储和共享面向对象的程序设计信息的标准。Microsoft和Marimba合作提出的开放软件描述（Open Software Description，简写为OSD）是用于描述软件的一个XML标准。

由于数据交换在电子商务尤其是企业－企业电子商务的核心作用，XML为电子商务带来了新的机遇和活力。

• 替代传统的EDI
  电子数据交换（Electronic Data Interchange，简称为EDI）是XML出现以前的数据交换标准，用于在异构系统间交换数据并进行事务处理，但由于EDI难于使用和实施费用昂贵等缺点使得它没有成为数据交换的主流技术。XML的出现，使得数据交换更为廉价和方便。
• 智能代理
  智能代理能够理解接收到的数据，然后作出相应的反应。如果数据是结构化的XML数据，智能代理就能够非常容易利用已有的知识库理解数据。XML的出现，为智能代理的发展提供了新的推动力。

4. Web应用

由于XML是由SGML特别为Web简化的，因此XML文档将成为Web资源的重要组成部分，XML使得搜索引擎更为智能和准确。XML还可以用于建立多层Web应用。

• 集成不同数据源
  XML文档可以用来描述包含在不同应用的数据，从Web页面到数据库记录等，Web应用的中间层服务程序将这些用XML表示的数据组合起来，然后提交给客户端或者下一步的应用。XML还提供了客户端包含机制，可以将多个来源的数据集成在一个文档内显示。
• 本地计算
  XML数据传输到客户端后，客户端可以利用XML分析器对数据进行解析和操作，在完成系统所需功能的同时，合理分配客户端和服务器的负荷。比如：数据库记录可以直接传输到客户端，然后再进行排序，传统的HTML就无法做到这一点。
• 数据的多种显示
  XML将内容与表现分离，XML只描述数据的结构和语义，显示外观则通过样式单文件（CSS或XSL）进行描述。因此，只需在显示时配置不同的样式单，即可实现多种显示效果。
• 网络出版
  随着互联网的发展，网络已经成为一种新的媒体，人们在网络上发布各种信息，信息的发布形式和发布语言也多种多样，其中基于XML的显示技术和显示语言发挥了重要作用。比如eBook、eNewspaper等，就利用了XML的显示语言。
• 支持Web应用的互操作和集成
  Web界面定义语言（Web Interface Definition Language，简称为WIDL）是webMethods定义的一个XML应用，它是一个能够用于Web的资源和企业应用接口的语言标准。通过它，Web应用可以自动存取Web资源和企业应用。
  

其实，XML的应用在现阶段虽然不能称之为随处可见，但是只要留心一下，就可以发现身边其实早就存在着XML应用。

在Netscape Navigator 4.06以后的版本中，有一项功能称为“What s Related”，用来指示与当前浏览的网页相关的站点或网页，在其中起作用的关键技术，除了数据库和搜索引擎外，就是资源描述框架RDF（Resource Description Framework）。RDF是用于处理元数据的XML应用。当用户按下“What s Related”的菜单或按钮时，浏览器将当前浏览的网页的网址传递到Netscape公司的服务器上，服务器在数据库中找到该网页，并且将与这个网页关系最密切的其他网页和相关资料，以RDF格式传送回浏览器。然后以菜单方式呈现给使用者，供使用者选择。那么，究竟什么是RDF呢？它又是如何在这一应用中发挥作用的呢？

RDF是一个处理元数据的XML应用，所谓元数据，就是“描述数据的数据”或者“描述信息的信息”。也许这样解释元数据有些令人难以理解，举个简单的例子，书的内容是书的数据，而作者的名字、出版社的地址或版权信息就是书的元数据。数据和元数据的划分不是绝对的，有些数据既可以作为数据处理，也可以作为元数据处理，例如可以将作者的名字作为数据而不是元数据处理。

众所周知，对资源的描述是领域和应用相关的，比如对一本书的描述和对一个Web站点的描述是不一样的，即对不同资源的描述需要采取不同的词汇表。因此RDF规范并没有定义描述资源所用的词汇表，而是定义了一些规则，这些规则是各领域和应用定义用于描述资源的词汇表时必须遵循的。当然，RDF也提供了描述资源时具有基础性的词汇表。

通过RDF，人们可以使用自己的词汇表描述任何资源，但人们更乐意将它用于描述Web站点和页面，由于使用的是结构化的XML数据，搜索引擎可以理解元数据的精确含义，使得搜索变得更为智能和准确，完全可以避免当前搜索引擎经常返回无关数据的情况。当然前提是RDF和标准化的RDF词汇表在Web上广泛使用，而且搜索引擎需要能够理解使用的词汇表。

简单而言，一个RDF文件包含多个资源描述，而一个资源描述是由多个语句构成，一个语句是由资源、属性类型、属性值构成的三元体，表示资源具有的一个属性。资源描述中的语句可以对应于自然语言的语句，资源对应于自然语言中的主语，属性类型对应于谓语，属性值对应于宾语。由于自然语言的语句可以是被动句，因此前面的简单对应仅仅是一个概念上的类比。

下面的例子描述了三个知名的XML站点，其中使用的词汇表是Dublin Core定义的元素集合，由命名空间http://purl.org/DC/指定，标记CREATOR表示资源的人员或组织，标记TITLE表示资源的名称。Dublin Core元素集合还包括其他已经确定的元素，另有一些元素还处于实验阶段，感兴趣的读者可以查阅相关资料。

关于RDF的深入讨论，已经超出了本节的范畴，有兴趣的读者可以参考http://www.w3.org/TR/rdf-schema和http://www.w3.org/TR/REC-rdf-syntax，这两个文件是W3C定义的RDF规范。

前一小节介绍的是Netscape推出的技术，事实上，在XML的应用上，IE也不甘落后。在Internet Explorer 4.0及其以后的版本中，Microsoft推出了“频道”（Channel）的概念，用户可以通过订阅频道实现站点更新内容的自动获取。在频道定义中所使用的格式CDF（Channel Definition Fomat），也是一个XML应用。

使用过IE的人可能都知道，频道使Web站点能自动通知读者重要信息的变化，这种技术称为“Web广播”（Web Casting）或“推送”（push）。可能Microsoft早期希望将CDF发展成为一个标准，因此在CDF推出初期将其提交给了W3C，但W3C对CDF显然不够热心，自从1997年3月9日提交后，W3C一直没有正式承认接收该规范，而且估计以后也不会采取进一步的动作。因此Micosoft在以后的CDF版本更新都没有公布其完整文档。现在唯一支持CDF的浏览器就是Internet Explorer（4.0以上版本），其他的浏览器都不支持而且似乎也不准备支持CDF。

CDF文件是一个定义了读者和站点内容的连接参数的XML文件，它与站点上的HTML文件分开，但链接到某个或某几个HTML文件上。浏览器根据定义的参数决定新内容传递的方式，包括：

• 将频道添加到频道栏并且订户可以随时检查；
• 新内容通过电子邮件通知订户，订户可以随时加载频道；
• 浏览器定期检查站点并自动更新和下载改变的内容。

CDF文件是站点的附加物，通常将定义好的CDF文件链接在站点的主页，比如可以在主页中插入如下链接：

如果用户使用的是支持CDF的浏览器，可以点击这个链接订阅该频道。否则将下载这个CDF文件。

CDF实际上是Micosoft用XML定义的一个词汇表。下面是Internet Explorer自带的一个简单的CDF文件，本例并没有包括所有的CDF元素，只是希望通过这个例子说明CDF和XML的关系。

其中第一行是XML声明。第二行是CDF文件的根元素CHANEL，它是CDF文件唯一要求的元素，根元素CHANEL必须包含一个HREF属性以指定监视修改的页面。第三行是ABSTRACT元素，其内容是描述频道的文本，该描述通常出现在频道栏的工具提示窗口。

关于CDF词汇表的其他元素，本节不再做详细介绍。一方面原因在于CDF并没有获得业界的广泛支持，另一方面在于Microsoft没有公布当前版本CDF的完整DTD。而且Microsoft提供了一个软件CDF Generator（http://msdn.microsoft.com/downloads/tools/3rdparty/423.asp），可以利用它生成自己站点的CDF文件，根本无需了解CDF的内部细节，下图是CDF Generator运行时的主界面。

如果你确实希望了解CDF的内部细节，可以在http://www.w3.og/TR/Note-CDFSubmit.html处获取早期的CDF定义文档，但这是一个过时的文档，与CDF的当前版本有一定差距。当前版本的CDF定义可以参见MSDN文档（Microsoft Develop Network）和Microsoft的站点（http://www.microsoft.com/）。

简而言之，电子商务就是利用电子手段尤其是互联网进行商务活动。电子商务的出现和发展，已经并仍然在改变个人和团体的商务活动的模式。电子商务延伸了商务联系，能够极大地降低成本，加快商品和资金流通的速度，增强市场信息的可预测性和各种商务活动的可控制性。不难看出，将来能在市场中取胜的，必是能充分利用电子商务的商家。

从技术上说，电子商务是通过互联网传输和交换商务数据，并能根据商务数据进行人工或自动处理。数据的标准化在数据传输和交换过程中起着至关重要的作用，它决定了数据的语义，增强了数据的可读性和可理解性。XML的可扩展性和自相容性，使它成为数据标准化和信息交换的有力工具。

电子商务的发展，首先出现的是企业－消费者（B2C）和消费者－消费者（C2C）模式。在这些模式当中，由于数据的传输路径是Web服务器－浏览器或者浏览器－Web服务器－浏览器，数据最后发布在浏览器上，供人们阅读和理解，侧重于信息对人的可理解性，因此数据表现被提到一个重要的地位，数据的结构化显得较为次要一些，侧重于数据表现的HTML基本上能够满足这些应用。但是随着电子商务的发展，HTML在B2C和C2C这两种模式中已经开始显得力不从心。

首先，我们知道，从数据库提取信息生成HTML页面后，信息的语义、结构已消失殆尽，如果建立在其基础上的进一步应用需要用到这种结构化信息，开发就非常困难。例如现在电子商务中时兴的比较购物，它需要在各个电子商务网站的页面中抓取商品的信息，将同一品名的商品放在一起比较。如果各个电子商务网站都按照自己的方式组织页面，对于从事比较购物的网站，难度就可想而知。

相反，XML可以保持数据的结构。现有的主流关系数据库如SQL Server 7.0、Oracle 8i和Informix等都提供了对XML的支持，可以直接保存或生成XML文件。再为其配上相应的XSL样式文件，就可以将数据直接显示在浏览器上。而且，XML使得数据在数据库之间交换显得非常容易，有人预测，XML将是数据在数据库之间交换时的标准方式。

其次，现在很多电子商务网站都提供个性化服务，例如Web服务器可以根据客户的定制生成和传输不同的页面。事实上，不同显示效果的页面之后的数据是相同的，因而一个自然的想法就是将数据及其表现分离开来。显然，XML在这方面比HTML要擅长得多。利用XSL，无须改变数据内容本身，只传送样式文件就可以实现页面的重新显示。

随着企业－企业电子商务（B2B）尤其是供应链管理的出现，数据的传输路径转变为Web服务器－Web服务器，数据的传输过程不需要浏览器。Web服务器不仅需要接收对方传送的数据，而且还应该能够理解数据的含义，并能根据数据作出相应的处理。两个Web服务器直接进行通信，无需人工干预，在这种情况下，数据的结构化和标准化就显得至关重要。

在电子商务的发展过程中，传统的EDI作为数据交换的方式，对数据的标准化起到了重要的作用。EDI将商业文件如订单、发票、货运单、报关单等按统一的标准，编制成计算机能够识别和处理的数据格式，在计算机之间进行传输。不过，传统EDI存在着巨大的局限性：

• 首先，EDI需要建设专用网络，开发专用程序，投入巨大，因此它的应用往往仅局限于少数大银行和大企业。
• 其次，EDI数据侧重于信息对机器的可读性，人工阅读EDI数据简直就是灾难。
• 再次，所有EDI数据都不能通过Web来进行数据搜索和定位，也无法在Web上显示，而这正是那些现代INTERNET小型企业与一些不固定商业伙伴进行小型交易的最基本要求。
• 最后，传统EDI经过几十年的发展，EDI信息标准仍然得不到统一，没有形成一个全球通用的标准。现在国际上存在两大标准体系：一个是流行于欧亚由联合国欧洲经济委员会（UN/ECE）制订的UN/EDIFACT；另一个是流行于北美由美国国家标准化委员会（ANSI）制订的ANSI X1.2标准。此外，各行业也有自己的行业标准，如：CIDX（化工）、VICX（百货）、TDCC（运输业）等。

XML自从出现以来，以其可扩展性、自描述性、自相容性等优点，被誉为信息标准化过程的有力工具，基于XML的标准将成为以后信息标准的主流。由于XML提供了一个四海通行的方法来传送自我描述的资料，因此它是将文件和结构化资料一起移动和沟通的最佳机制。不过，为了保护企业在EDI上的巨大投资，传统的EDI也没有被彻底废除，而是与XML相结合，形成了XML-EDI。

XML技术对电子商务有重大影响，XML的人机互动式架构提供了使用者与电脑之间的互动交流，利用其可延伸性及自我描述特性，电子通讯文件可以在企业间的应用程式中自动传输、处理及储存，不同厂商的电子商品目录可以在同一个使用者界面同时呈现，资讯的搜寻变得更为精确快速，不同系统间可以流畅地互通，不同网站之间的资料得以动态共享，强化了使用者与系统之间的聚合性。

据Gartner的估计，三年以后到2003年，企业―企业的网上数据流量，将10倍于企业―个人的网上数据流量，而其中80%的数据，将采用XML格式。由于XML为信息的自动交换提供了必要的技术支持，因此有人提出“eXe”将成为最基本的连接模式，其中的“e”是指企业(enterprise)，而“X”就是XML。

自从XML出现以来，基于XML的应用取得了长足的发展，随着客户化工具的出现，浏览器对XML支持的增强，可以说基于XML的电子商务已经基本准备就绪。

1. 成熟的标准体系

自从XML1.0规范成为正式标准以来，XML的整个标准体系正在逐步成熟。虽然还有许多XML相关的规范正在制订之中，但对电子商务的应用而言，也许只需要XML和XSLT就足够了。电子商务的方案提供商和组织利用XML定义标准和词汇表，网站的建设者则利用XSLT将XML文件转化为HTML文件或其他的XML文件，并显示在浏览器或其他显示设备中。

现在已经有很多企业和组织开始利用XML定义标准和词汇表，形成了一些标准，而且每个标准都有一些工具和应用厂商支持，为从事电子商务的人们提供了许多选择。不过，也许对于定义这些新标准的人而言，现有的标准体系还存在一个“洞”需要填充，这就是schema规范。在schema成为正式标准之前，DTD仍然是定义标准和词汇表时的唯一选择。

2. 客户化工具

自从XML出现以来，人们抱怨最多的也许就是客户化工具的缺乏，尤其是可视化工具。人们希望能够象利用现有的HTML编辑器生成HTML文件一样，能够有可视化的XML编辑器能够直接生成XML文件和XSL文件，无需详细了解XML内部的机制。随着时间的推移，可视化的XML工具已经开始出现，比如SoftQuad的XmetaL和eXcelon的Object Design都提供了可视化编辑XML的能力。除此之外，软件提供商还为XML提供了各式各样的小工具，包括XML服务器，schema设计工具等等。

XML的客户化工具为XML使用者提供了巨大的支持，他们可以无需了解XML的内部机制，直接使用XML，使得XML的广泛应用成为可能。

3. 浏览器支持

也许人们会担心浏览器对XML的支持情况。事实上，当前的主流浏览器中，IE5.0已经有了一个内置的XML分析器和XSL转换器，Netscape对XML的支持落在了后面，仅限于XML分析。随着时间的推移，相信浏览器对XML的支持将会越来越强。

但是，即使没有本地的浏览器支持，XML的应用仍然不成问题。对于大多数应用而言，数据可以放在数据库中，需要时将数据取出来形成XML文件，然后加上XSL文件，在服务器端生成HTML文件，发送到浏览器上。甚至于可以在服务器端判断客户端的显示设备，根据显示设备应用不同的样式单，生成显示设备能够支持的页面发送过去。至于XML文件的生成，如果数据库支持XML，可以从数据库直接存取XML文件；如果数据库不支持XML，工作可能要多一些，系统需要把查询结果（一般而言是一个二维表）转化为XML。

当前，基于XML的电子商务标准比较多，一般也比较复杂。在5.3.5小节中我们简要地介绍了其中的几个，本节仍不打算深入标准的内部去探讨其实现，任何一个标准的深入介绍都足以形成一本专著，我们只帮助大家归纳一下这些主要标准的体系构架。

当前的电子商务标准可以分为以下三类：

• 体系结构相关的标准：这类标准关心的是整个电子商务的体系结构，包括通用XML消息的标准，schema库等；
• 功能相关的标准：这类标准关心供应链中各个环节的数据交换；
• 业界相关的标准：这类标准与所涉及的行业相关，是某个行业内部的数据交换标准。

1. 体系结构相关的标准

这类标准主要包括几个正在制定和已经完成的体系。

• BizTalk
  BizTalk是Microsoft发起的电子商务的schema库，配合的产品有Microsoft的BizTalk服务器。在3.2.3节中我们曾给出了关于它的详细介绍。
• ebXML
  ebXML是联合国UN/CEFACT小组和OASIS共同发起的计划，要在15-18个月内制定出基于XML的全球范围的电子商务数据交换的标准。ebXML涉及的方面比较广，包括：
  • 体系结构
  • 核心部件
  • 消息的封装和传输
  • 注册和保存schema的库
  • 业务处理模式

  这个标准正在制定中，期望会是一个比较全面的标准。它的Requirment、消息封装和传输已经有草案。

• eCo
  eCo是CommerceNet 1998年就开始的一个计划，CommerceNet是由银行、通讯公司、增值网提供商、ISP、在线服务，软件和服务公司和最终用户等组成的协会，现有成员600多家公司和组织，其目的是促进B2B电子商务的发展。eCo的体系结构有点儿象网络的分层结构，它分为七层：
  • 网络（networks）
  • 市场（markets）
  • 业务（businesses）
  • 服务（services）
  • 交互作用（interactions）
  • 文档（documents）
  • 信息项（information items）

  每一层都有类型注册，接口是向外发布的，文档要包裹一层（document wrapper），发布的接口必须有一些必要的方法进行查询，查询返回的文档是特定的DTD的xml文档，每层的方法和返回的文档的结构都在规范中有描述。
  后两层eCo推荐使用simple_EDI和xCBL这两种XML的交换格式。

• RosettaNet的PIP（Partner Interface Process）和RosettaNet应用网络标准。
  RosettaNet由诸多IT业的巨子组成的一个标准化组织，目前会员包括象Cisco Systems、Compaq、GE、HP、IBM、Intel、Microsoft、NEC、Oracle等60个企业，目的是制定一个适用于IT产品，通过WEB技术在网络上实时进行企业级交易的电子商务标准。这个标准也是分层结构，包括：
  • 动作（Action）
  • 事务（Transaction）
  • 处理（Process）
  • 服务（Sservices）
  • 消息处理（Message Handling）
  • 代理（Agent）
  • 传输（Transfer）
  • 安全（Security）

  每一层的消息都会加一些信息上去，如header，它的消息都是http的MIME消息，其中的XML正文是内容。这个标准比较注重事务处理和安全性。RosettaNet用guideline定义和约束供应链中的消息。guideline其实就是消息的DTD及其说明，但其描述能力比DTD强。

2. 功能相关的标准

这类标准关心电子商务的具体环节的数据交换。XML/EDI就是这一类的标准，另外，我们前面讲到的xCBL、tpaML、cXML、WIDL（Web界面定义语言）和OTP（开放贸易协议）也都属于此类。

3. 业界相关的标准

这类标准主要涉及一个行业，定义行业内部的词汇表。由于它们涉及的是特定的行业，因此数量非常的多，而且随着时间的推移，这类标准将更多。这里给出两个典型的例子：

• 开放金融交换格式（Open Financial Exchange Format，简写为OFX），是一种用于描述保存在个人财务软件中的金融数据的标准。
• 个性化印刷置标语言（Personalized Print Markup Language，简写为PPML），是PODi组织于2000年2月发布的个性化印刷格式语言，并已开发出相应的产品，该标准用于按需印刷（ondemand-print）。

随着网络的飞速发展，互联网已经成为继报刊、电台、电视台之后的一种新型媒体。在1998年5月举行的联合国新闻委员会年会上，互联网被正式冠以“第四媒体”的称号。

相对于传统媒体，数字化的第四媒体具有难以比拟的优点。它具有信息的综合性和丰富性、充分的互动性与开放性、信息传递的快捷与超时空以及信息的大容量和灵活性。因此，互联网出现以来，就受到一些传统媒体如美联社、路透社、CNN等的关注，它们迅速登陆互联网，利用互联网提供新闻和经济信息服务。现在的网络媒体基本上可以划分为以下几类：传统媒体上网、传统媒体与其他行业共建网站、无传统媒体依托的网络媒体。也正是由于传统媒体和网络媒体的广泛合作，使得跨媒体出版愈来愈成为一种趋势。

网络出版自从出现以来，用于信息发布的主要是HTML技术，但是这种方式在跨媒体出版时遇到了极大的困难。比如现在的报纸大多需要同时在网上发布和印刷发行，报社不得不需要两组人力，同时进行印刷组版和网络组版。下图示意了大多数报纸的现行作业：

如果能够将筛选编辑过程合并，然后分别进行组版，就可以节省人力，从而达到降低成本的目的，如下图：

另外，随着后PC时代的到来，各种如信息家电、手机、PDA等新的上网设备层出不穷。单独的HTML已经不能满足网络出版的需求，显示语言也各不相同。如果根据显示设备的要求制作多个版本会造成人力物力的巨大浪费，系统需要一种制作一次出版多次的技术。XML的内容与显示相分离的特点，使得它在跨媒体出版上有着得天独厚的优势，如图所示：

随着互联网技术的发展，人们希望能够在线阅读书或报纸，于是乎电子书和电子报纸应运而生。

电子书和电子报纸分别是eBook与eNewspaper的中文译名，是互联网发展的又一新兴产物。它们分别采用数据化文档的形式组织书和报纸的内容，读者可通过特制的阅读工具来阅读其中的内容。

目前已经上市的eBook阅读器有四种，它们是SoftBook公司推出的SoftBook、 NuvoMedia推出的RocketBook、GlassBook推出的GlassBook和EveryBook推出的EB Dedicated Reader。其外观分别如图所示：

SoftBook	RocketBook
打开的EveryBook	关闭的EveryBook
GlassBook

这些电子书阅读器都可以通过连线与计算机相连，然后下载网上书店的书籍，并具有加书签、标注和书架管理等功能。可以想象，电子书的普及将改变目前传统出版的工作流程，对面向以纸介质为主要承印物的传统的出版及印刷行业会造成较大的冲击。

随着电子书的出现，另一种新媒介——电子报纸也呼之欲出。新型的电子报纸既不同于传统的纸介质报纸，也不同于电子书阅读器所采用的LCD液晶显示器，它是用全新的材料制作而成。“纸”的材料采用一种类似于玻璃纤维的物理材料，而“墨”则是一种新研制的电子墨，如下图所示。目前IBM、施乐、eInk等公司正在致力于eNewsPaper的阅读器及电子墨的研究，并已有原型产品诞生。

有了电子书和电子报，可大大减少纸张的消耗，节约资源。另外，在办公、出游时携带薄薄的一本电子书，相当于随身携带一个小型的图书馆，信息、资料一应俱全，真是方便之至。

eBook近两年来发展很快，受到了包括作家、出版商、书刊销售商、软件开发公司、硬件制造厂商的普遍关注，并成立了一个由四十多个组织组成的Open eBook Authoring Group（以下简称为OEB组织）。参加的组织中有eBook先锋Nuvomedia Inc.、SoftBook Inc.、GlassBook Inc、Libius Inc.、EveryBook Inc.，以及Microsoft、Adobe、Motorola、Nokia等一大批软件及硬件厂商，还包括了一些著名的印刷出版商。经过OEB组织的努力，于1999年9月21日完成了OEB1.0标准的制定，从此eBook有了统一的文档数据格式标准。

OEB1.0是“Open eBook Structure Specification 1.0”的缩写，OEB文档基于HTML和XML语言，是标准的XML文档。它的出台，从根本上统一了eBook的文档数据存储方式，保证了消费者购买任何一个品牌的阅读机都可正确阅读eBook文档，使得消费者不用承担由于购买阅读机而带来的格式兼容方面的风险，奠定了建立eBook市场的坚实基础。在5.3.7节中，我们给出了对于OEB的简要介绍。

随着Internet应用的普及，eBook和eNewsPaper将得到广泛的应用。前面所介绍的几种电子书的阅读机厂家都拥有自己的网上书店，开数字化书刊出版及发行的先河，必将带动整个行业进一步向数字化发展。进入到21世纪以后，中国的网上书店也如雨后春笋，显示出勃勃生机与发展实力，目前已有企业在进行eBook的研究与开发，台湾也有厂商投资生产eBook阅读机，相信不久将会看到中文eBook阅读机的面世。这是一个刚刚启动的市场，也是一个极有潜力的市场。它将极大地促进网络出版的发展，它的出现，标志着印刷出版业进入到了一个崭新的时代。

1990年以来，互联网和移动通信的发展极大地改变了人们的生活、学习和工作。人们不仅仅将互联网视为一种手段或工具，更将它视为一种生活方式，他们要求能够随时随地与互联网保持连接，并且能够在移动中获取信息。但是由于互联网需要与固定的有线网相连，无法满足人们的这个需要。移动电话生产商和电信运营商顺应人们需求，利用无线上网技术，将互联网与无线网结合起来。

随着移动电话与互联网结合，无线上网的趋势正在形成，新的移动通信标准使得移动终端的带宽可以达到最高2Mbps。有人预言，随着无线带宽的增加和无线上网技术的迅速发展，.move将替代.com成为新的潮流。一些网络先锋将电子商务应用与无线上网结合起来，开始展开移动电子商务的业务。在这过程当中，WAP（Wireless Application Protocol）起着决定性的作用。

WAP的提出是为了满足人们在移动中连接互联网的需要，相对互联网而言，无线数据网络的带宽窄，连接的稳定性差，手机的CPU功率相对于PC会更小，内存和显示器更小，输入设备更为简单等等。由于无线网络和移动设备的这些特点，使得WAP规范无法直接利用互联网的技术和标准，而必须重新定义符合移动设备和无线网络特点的规范。1997年6月，Phone.com联合了Nokia、Ericsson、Motorola合作建立了WAP论坛，旨在利用已有的互联网技术和标准，为移动设备连接互联网建立全球性的统一规范。它们的工作很快有了成果，在1998年5月，推出了WAP规范（Specification）1.0版，并于1999年11月发布最新的1.2版。

WAP规范1.2版包括了31个文件，它定义了一种无线应用程序的编程模型和语言，并且定义了一套用来实现无线互联网访问的规范。其中主要定义了以下几种组件：

1. WAP编程模型

这个模型在很大程度上利用了现有的WWW编程模型，这样可以给应用开发人员带来许多好处，可以最大限度地利用他们原来掌握的经验和各种开发工具。WAP编程模型还针对无线环境的通信特点对原有的WWW编程模型进行了优化和扩展，见图示：

2. 无线置标语言（WML）

WML是利用XML1.0标准定义的面向显示的置标语言，特别适合于在性能方面严重受限的手持设备。WML和WML Script并不要求用户使用传统的PC机键盘或鼠标进行输入，而且它设计时就考虑到了手机的屏幕尺寸限制。使用WAP网关，所有的WML内容都可以通过Internet使用HTTP 1.1请求进行访问，因此传统的Web服务器、工具和技术可以继续使用。在5.3.6节中对WML给予了详细的描述。

3. 微浏览器规范

这个规范与标准的Web浏览器规范类似，它定义了一个适合于手持设备的功能强大的用户接口模型。这个规范定义手机如何解释WML和WMLScript并且显示给用户。

用户通过上移键和下移键而不是鼠标在各个卡之间来回进行导航。为了保持与标准浏览器的一致，微浏览器还提供了各种导航功能如Back、Home、书签等。微浏览器允许具有较大屏幕和更多特性的设备自动显示更多的内容，就像传统的浏览器当浏览窗口扩大时能显示更多的信息一样。

4. 轻量级协议栈

这个协议栈将无线手机访问Internet的带宽需求降到最低，保证了各种无线网络都可以使用WAP规范。通过使用WAP协议栈可以节省大量的无线带宽。要完成同样一个访问操作，使用WAP协议栈涉及到的包数量不到使用全标准的HTTP/TCP/IP协议栈的一半，这对于带宽严重受限的无线网络来讲无疑是十分有用的。

5. 无线电话应用（WTA）框架

它允许无线手机访问各种电话功能如呼叫控制和来自WML Script applet中的信息。这允许商家开发各种电话应用并且将其集成到WML/WML Script服务中。如呼叫转移这样的服务，商家可以提供一个用户接口，提醒用户是准备接受呼叫、转移到他处还是将其转发成一个语音邮件。

6. WAP网关

WAP规范使用标准的Web代理技术将无线网络与Web连接起来。通过将处理功能集中在WAP网关中，WAP结构大大减少了手机上的操作负载，因此为手机实现价廉物美提供了基础。如，一个WAP网关一般可以使用所有的DNS服务来解析URL中使用的域名，因此就不再需要手机来完成这个计算任务。还可以利用WAP网关来为用户提供各种服务并且可以帮助网络服务商防止诈骗和服务利用, 见下图。

一个WAP网关一般包括以下功能：

• 协议网关：协议网关将来自WAP协议栈的请求翻译到WWW协议栈（HTTP和TCP/IP）中；

• 内容编码器和解码器：内容编码器将Web内容翻译成紧密编码的格式，以减少通过无线数据网络传输的数据包的大小和数量。

下面，我们再来详细讲一讲所谓的WAP协议栈。如下图所示，WAP的协议栈采用层次化设计，这为应用系统的开发提供了一种可伸缩和扩展的环境。每层协议栈均定义有接口，可被上一层协议所使用，亦可被其他的服务或应用程序直接应用。在设计中，WAP充分借鉴了Internet的协议栈思想，并加以修改和简化，使之可以有效应用于无线应用环境。

1. WAE层
   WAE（Wireless Application Enviroment，无线应用环境）是一个结合了WWW和移动通信技术的常用编程环境。WAE的主要目的，就是要建立一个可互操作的环境，以便在用户终端部分和服务供应商部分开发程序或提供服务，而不去考虑各种无线网络平台的不同。WAE包括一个微浏览器环境，以及：

• WML（Wireless Markup Language）。这是WAP制定的基于XML的置标语言；

• WMLScript。这是对WML语言的补充，与JavaScript很相似；

• WTA/WTAI（Wireless Telephony Application）。这是一个通信服务和编程接口；

• 内容格式。这是WAP定义的一组数据格式，其中包括图片，电话簿，日历信息等等。

2. WSP层
   WSP（Wireless Session Protocol，无线会话协议）是WAP的应用程序层，用于对两种会话服务提供统一的接口：一种是建立在事务层协议WTP基础上的面向连接的（connection-oriented）服务，另一种是建立在安全或非安全的数据报文（datagram）服务（WDP）基础上的无连接服务。

3. WTP层
   WTP（Wireless Transaction Protocol，无线事务协议）运行于数据报文服务之上，并提供部分的面向事务（transaction-oriented）协议（因为移动数字终端属于“瘦”客户端，及它无法支持大数据量的事务服务）。

4. WTLS层
   WTLS（Wireless Transport Layer Security，无线传输层安全）是WAP在另一个工业标准TLS（Transport Layer Secureity，传输层安全）协议的基础上制定的一个安全协议。其制定的目的就是在窄带宽的通讯频道上安全地使用WAP的传输协议。

5. WDP层
   WDP（Wireless Datagram Protocol，无线数据报文协议）是WAP的传输协议。作为一种通用的传输服务，WDP为其上的其他WAP协议提供统一的服务，并向其下的各种承载器（Bearer）进行透明的通讯。正是因为这种透明性，WDP之上的安全、会话和应用层可以与WAP结构中最下层的各种无线网络互相独立。

6. 承载器（Bearer）层
   各种承载器所能够提供的服务是不一样的，根据数字终端的接受/发送能力，误码率，和延迟时间的不同，承载器所能够提供的服务质量也会不一样。WAP协议可以容忍这些差异，或者可以对这些差异进行补偿，从而达到对上层协议透明。

7. 其他服务和应用
   通过WAP定义的一系列接口，外部服务或程序可以访问WAP协议堆栈的各个层面。

总之，WAP创造了一种商业机会，它使得现有的业务或新的业务可以每时每刻被用户访问，它可以发掘出各种崭新的、甚至目前无法想像的增值业务，这为电信业务运营商提供了创造丰厚利润的宝贵商业机会。

WAP最有潜力的应用是与电子商务结合，实现移动中的电子商务。例如随时参与证券交易，使用移动网络银行业务，在移动中实现网上购物。现在您随身可能携带钱包、电话本、信用卡、手机等，在将来，可能您只需携带一部具有WAP功能的移动电话，就可以完成打电话、付账、买车票、管理个人工作安排等一系列事情。

但是，行业内部也有不同的声音。以通信市场调查咨询而闻名的美国Ovum公司在其2000年5月23日发表的报告“WAP市场策略”（WAP Market Strategies）中警告：“采用WAP技术的第一代手机已投放市场，但这种技术未必就是最好的。想抢搭WAP头班车的笠当匦肭宄厝鲜兜絎AP不是唯一可以利用的、最好的技术。”Ovum公司提醒那些参与移动因特网服务的企业在制定战略时，需要考虑到WAP以外的技术，诸如以XML为基础的技术等。

XML自推出以来，尤其是在1998年2月成为W3C推荐标准以来，受到了广泛的支持。各大软件厂商如IBM、Microsoft、Oracle、Sun等都积极支持并参与XML的研究和产品化工作，先后推出了支持XML的产品或者将改造原有的产品以支持XML，W3C也一直致力于完善XML的整个理论体系。

XML虽然获得了极大的支持，但是它还有很长的路要走。首先，XML的规则只是迈出了第一步，还有许多技术细节没有解决。其次，现在虽然出现了一些XML工具和应用，但是其市场反应还有待进一步观察。另外如何让更多的人迅速学会使用XML，并利用它进行开发，进而促进XML的应用也是一个问题。因此XML的出现和迅猛发展并不意味着HTML即将退出互联网舞台，由于HTML的易学易用和非常多的工具支持，HTML将在较长的时间里继续在Web舞台上充当主角。但是如果用户想超越HTML的范围，XML将是最佳的选择。

另外，由于XML是用于定义语言的元语言，任何个人、公司和组织都可以利用它来定义自己的置标语言（通过DTD或schema表示），这虽然是XML的魅力和灵活性之所在，但同时也是XML的最大问题之所在。如果每个人、公司和组织都定义了自己的置标语言，它们之间的通信就会出现困难。因此在一些领域先后出现了一些标准化组织，它们的任务就是规范本领域的置标语言，形成统一的标准，使得在本领域内的通讯成为可能。但在标准推出并得到广泛认可之前，各自为政的局面将继续下去。更糟糕的是，由于对应用的理解不一致和商业利益等原因，同一个领域也许还有多个标准化组织，它们形成的置标语言并不完全兼容，使得采取不同标准的计算机仍然难以通信。

无论如何，XML的出现使互联网跨入了一个新的阶段，它将成为因特网领域中一个重要的开发平台。XML的诞生已经而且将继续促使全新种类的应用程序的产生，而这些新的应用程序又将需要新的软件和硬件工具。可以预测，无论是在软件还是硬件上，XML都将开辟一系列的新市场，促成互联网上新的革命。

XML可以分为三层结构，数据表现层，数据组织层和数据交换层。在我们对表现层和数据组织层有了一个比较全面比较深入的了解后，最后再来看看XML的最底层——数据交换层。

我们知道，从整体上讲，XML定义的实际上是应用间传递数据的结构，而且这种结构的描述不是基于二进制的、只能由程序去判读的代码，而是一种简单的、能够用通用编辑器读取的文本。利用这种机制，程序员可以制订底层数据交换的规范，然后在此基础上开发整个系统的各个模块，而各模块之间传输的数据将是符合既定规则的数据。另外，XML还允许为特定的应用制定特殊的数据格式，并且非常适合于在服务器与服务器之间传送结构化数据。

从应用的角度来看，XML信息交换大致可分为下面几种类型：数据发布、数据集成和交易自动化。

1. 数据发布

当今时代可以说是信息爆炸的时代，而互联网的出现又起到了推波助澜的作用，人们对信息的获取不再局限于读书看报，“到网上去冲浪”业已成为网迷们的口头语，并逐渐为越来越多的人所接受。在这种新生的环境下，业内人士不失时机地提出了“同一数据，多次出版”的解决方案。这种方式使我们只须制作和管理同一信息资源，就能够达到多种媒介出版和多种方式发布的目的。

先来看一下传统的信息发布方式--基于纸介质和CD-ROM的信息发布。虽然CD-ROM与纸张属于不同的介质，但是由于他们采用的数据格式基本一致，因此将他们归为一类。

早期制订的媒介无关的描述结构化信息的国际标准当属SGML-ISO 8879 1996，但是XML的出现，使得跨媒体数据发布技术又向前发展了一步。2000年5月18日，一个由数字印刷领域的知名厂家组成的所谓“按需印刷”组织（PODi）发布了“个性化印刷置标语言”（Personalized Print Markup Language, PPML）规范。这是一种基于XML的技术规范，主要用于带有可再利用内容文档的快速印刷。可以说，有了XML，跨媒体、多介质的数据发布显得更是顺水推舟。

最值得一提的是基于Web的网上发布。HTML作为Internet上Web网页描述语言已经为大家所熟知，而同HTML一脉相传的XML当然也可以在网上发布，当然需要配合样式信息（如CSS或XSL），因为正如你所知，XML只是定义文档内容而不涉及具体表现。另外，一种更为直接的Web发布语言也已诞生，那就是XHTML。XHTML是一种基于XML的超文本置标语言，也就是说，将以前用SGML定义的HTML改为用XML重新定义。现在，XHTML已经作为W3C的建议标准公布于众，相信在不久的将来会大有作为的。

2. 数据集成

如果说数据发布涉及到的是服务器-浏览器形式的数据交换，那么，数据集成则是一种服务器-服务器之间的数据交换。

现实世界中，一个企业需要涉及各种应用，小到上下班打卡系统，大到人事管理系统、财务核算系统、库存管理系统等等。一般情况下，各个系统可能是由不同的软件公司开发的，软件可能采用不同的技术、运行于不同的平台。但是企业的运作是一个整体，需要各个系统相互配合，于是应用系统间的数据交换接口就成为困扰信息主管的一大难题。于是，可能会出现这样的尴尬局面：月初，上下班打卡系统管理员将上月的员工考勤数据打包传送给人事部门（或用软盘或由网络发送），财务部门也将员工所在部门的销售业绩统计打包传送给人事部门，而后，人事干事运行一个批处理程序合并考勤数据和业绩统计，最后计算出员工工资。类似的情况几乎可以说比比皆是，但这是现实。企业缺乏一个顺畅的业务管理平台，不能将各部门的信息有机的集成在一起，势必造成管理上的混乱。

XML是解决这一问题的强大法宝。让我们再来分析一下这个假想的示例，其实，造成这种混乱局面的原因说到底，就是各个系统没有统一的数据结构约定。其后果不但是效率低下，而且信息冗余、重复开发也会造成资源的巨大浪费。在这种情况下，XML将起到粘合剂的作用，通过它，使得各业务模块有机结合，数据交换畅通无阻，从整体达到理顺业务操作的目的。

同所有软件开发规范一样，实现数据集成也必须分步骤、有条理地进行：

• 首先，要对整个业务进行调整，摈弃不合理部分。也许你会说：是不是跑题了，这同XML有什么关系？表面上看，似乎风马牛不相及，其实不然，基于XML的数据集成不仅仅是要进行系统开发，对旧有系统的合理改造也是很重要的。
• 然后，对业务模式归纳总结并从中抽象出数据交换模型，当然是基于XML的数据交换模型，也就是说制定数据交换的DTD或Schema。这是最基本的，但同时也是最为困难的一步。XML消息流要符合企业的信息流。不要将XML看作是用来代替对象或者开发软件的新方法，它应该是一种表达层次结构信息并且在不同的应用系统间传输这种信息的有效途径。在制定XML数据交换模型中，一个易犯的错误是直接照搬原来的数据格式而仅仅将其逐字逐句地"翻译"成XML，毕竟这是一个改造旧系统的"工程"，去粗存精方是上策。
• 最后一步，结合制定好的XML数据交换模型，运用XML DOM和SAX等技术编写应用程序，也可直接在原系统上进行改造。也许这是一件比较棘手的工作，毕竟任何新生事物和新技术的出现都会打破一些人的陈旧观念，但是好在学习XML及其应用开发技术并不是一件非常难的事情。

前面我们讲的是关于企业内部的XML数据集成，其实不同企业间的数据交换也是XML的用武之地。电子商务交易平台之间的XML B2B信息交换就是很好的例证。同企业内部的数据集成不同，企业间的XML数据集成需要由一个开放的、需要交易各方共同遵守的“法规”——基于XML的数据交换标准。目前全球电子商务的发展非常迅速，各种行业甚至跨行业的XML电子商务规范与框架层出不穷，其中比较有代表性的是：Ariba的cXML、IBM的tpaML 、CommerceOne的xCBL 2.0 、Microsoft的BizTalk框架、CommerceNet的eCo计划、RosettaNet的eConcert计划与PIP规范集以及联合国UN/CEFACT小组和OASIS发起的ebXML计划。XML技术的融入，使得企业间的交易不再局限于专网和特定的应用，而是可以在Internet上的不同系统间交换信息，不仅大大降低了成本，而且提高了数据的可持续性，从而保护了既有投资。

3. 交易自动化

XML也有助于提高应用的自动化程度。遵循共同的标准，使得应用程序开发商开发出具有一定自动处理能力的代理程序，从而提高工作效率。一个典型的应用是，开发这样一个智能代理程序：首先，该程序向某电子商务交易系统发出一个供货商资料查询请求，在得到应答后，自动连接答复中提供的所有供货商站点；然后，搜索预定商品的信息，并对获取到的不同商家针对该商品的价格、质量、服务等信息按一定的商业规则进行比较；最后，得出理想的结果，并自动向该站点下订单。下图即示出了这种自动交易的过程：

作为一种数据存储与交换的模式，长期以来文件系统占据了信息领域的大片江山，至今仍广泛采用。但是我们同时也会看到另一面。当今世界，技术发展迅猛，信息量也随之激增。的确，很难想象，面对成千上万的数据文件，如果仅仅通过文件系统来管理的话，那么无论是文件的搜索还是文件的调用，诸如此类的管理工作都将是不可能的。

现在，不论是什么行业，大多数关键数据都是放置于数据库中进行管理的，一来目前数据库技术已经相当成熟，二来其管理功能非常强大。以往的数据库应用，基本上都是基于C/S模式，数据底层结构一般来说都是相对固定，也就是说，开发出来的应用程序是针对具体的数据结构，其应用范畴受到一定限制，开放性较差。而XML作为一种可扩展性置标语言，其自描述性使其非常适用于不同应用间的数据交换，而且这种交换是不以预先规定一组数据结构定义为前提，因此具备很强的开放性，具有广阔的应用前景。为了使基于XML的业务数据交换成为可能，就必须实现数据库的XML数据存取，并且将XML数据同应用程序集成，进而使之同现有的业务规则相结合。

XML数据源多种多样，根据具体的应用，大概可分为下面三种：一种是XML纯文本文档，第二种是关系型数据库，第三种则来源于其他各种应用数据，如邮件、目录清单、商务报告等。其中，第一种来源，即XML纯文本文档是最基本的也是最为简单的，将数据存储于文件中，其最大的优点在于可以直接方便地读取，或者加以样式信息在浏览器中显示，或者通过DOM接口编程同其他应用相连。第二种数据来源是对第一种来源的扩展，其目的是便于开发各种动态应用，其优点则在于通过数据库系统对数据进行管理，然后再利用服务器端应用（如ASP、JSP、Servlet）等进行动态存取。这种方式最适合于当前最为流行的基于三层结构的应用开发。第三种数据由于来源广泛，因此需要具体情况具体对待。本小节的分析主要针对前两种数据来源进行分析。下图示意了XML的数据存取机制。

对于XML文档，可以通过DOM（Document Object Model）读取XML文档中的节点，这是最基本也是最底层的XML存取技术。正如上一章所述，DOM是W3C的一种技术标准，实际上是提供一组API来存取XML数据，可以通过JavaScript、Jscript、VBScript等脚本程序来调用，也可通过C++、Java等高级语言来实现。

其次，通过DSO(Data Source Object)进行XML的数据绑定可以方便地将XML节点同HTML标记捆绑，从XML文档中读取或写入数据，就象访问Microsoft Access或Microsoft SQL Server一样。DSO的工作方式有几种，一种是同DOM类似通过对XML节点树进行遍历来搜索节点，每次仅将节点数据同HTML的一个元素（如SPAN元素）相联；第二种同第一种的不同之处在于将节点数据同一个HTML多值元素（如TR元素）相联。

样式单CSS和XSL实际上通过给XML数据赋予一定的样式信息以使得其能够在浏览器中显示。CSS技术早在HTML3.2中就得以实现，其关键是将HTML中的元素同预先定义好的一组样式类相关联以达到样式化的目的，而XML同样也支持这种技术。XSL同CSS有些类似，不同之处在于它是通过定义一组样式模板将XML源节点转换成HTML文档或其他XML文档。XSL实际上也是符合XML规范的，它提供了一套完整的类似控制语言的元素和属性，最终可完成丰富多采的样式描述。

利用ASP在页面文档中嵌入ADO对象从数据库中提取XML数据是Microsoft对其ASP技术的一种扩展，功能非常强大。ADO取得数据后，可以调用DOM提供的API来动态生成XML文档，并进而同其他应用交换数据，或者直接在浏览器中显示。

最后，HTTP+SQL是Microsoft新近提出的XML数据库解决方案的核心，其基本原理是通过基于HTTP协议的URL方式直接访问SQL SERVER数据库，并返回以XML或HTML数据格式的文档。

前一节我们提到的XML信息交换类型，从某种意义上讲，都和数据库息息相关。先来看一下数据发布。如果有适当的浏览器（如Microsoft IE5.0），XML可以直接显示。但是现实情况是，大量的信息不可能都以XML文件的形式存在。在实际应用中，需要从数据库中提取信息，动态生成XML页面，然后加以样式化并发送到客户端浏览器。至于数据集成，同样也离不开数据库。企业间交换的B2B数据往往来自于数据库，比如产品目录、订单信息、用户资料等等。B2B应用在接收到XML数据后也可将其保存至数据库。最后，自动交易系统在得到不同供货商提供的商品价格、质量、服务等信息后，也可将其存入数据库，以便作为决策系统的数据来源。

上一节我们讲到了XML的数据存取机制，从一个较高的层面上分析了数据存取的多种方式。作为其中的一种，数据库数据存取机制似乎倍受青睐，但我们并未对此作比较深入的探讨，这一节里让我们对XML与数据库的关系进行一些详细的分析。

我们知道，数据库提供了对于大批量数据的有效存储管理和快速信息检索、查询的功能。从体系结构上看，数据库技术的发展历经了网络型数据库、层次型数据库、关系数据库、面向对象数据库。虽然面向对象数据库融入了面向对象技术，但是到目前为止，在各个领域使用最广的还是关系数据库。关系数据库管理系统（RDBMS）采用二维表格作为存储数据的模型，如下图所示，表格由行和列组成，一般情况下，列被称作"字段"用于表示组成数据有效信息的属性，而行则用于指示一条完整的数据记录。由于数据间的相关性可以通过表与表之间关键字（外键）来关联，由此产生了"关系"类型数据库的由来。

关系数据库有自己的查询语言——结构化查询语言（Structured Query Language, SQL）。SQL最初由IBM提出，后经不断发展，已于1986年成为业界标准并被广泛采用。SQL 是非过程性的。当SQL语句传送到数据库服务器后，服务器返回满足条件的结果或结果集（视具体查询项目而定）。一般情况下，大多数支持SQL的服务器系统均采用客户/服务器架构，现在又发展到更为先进的分布式处理架构。这样一来，SQL服务器既可以接收客户应用程序发送的查询请求，也可以接收其他服务器的查询请求，这些服务器可能是其他SQL服务器，也可以是XML服务器。

与XML文件不同，数据库将不再扮演简单的数据容器。数据库可以相当灵活，因为可以存储在数据库中的不仅仅是单调而枯燥的数据，还有适合于应用需要的规则和模式。针对XML数据，一般有两种存储方式：一是将其按结构层次拆分开来分别存于不同字段，二是将XML文档原封不动地存入数据库。实际应用中，后者的应用环境将受到一定限制，因为关系数据库不能很好地处理大容量的结构化的信息和文本数据。当然，也可以将结构化置标文本分解成尽可能小的部分，然后转换成数据库中的字段来存贮，但是这样在数据库的检索、索引方面会增加许多额外的工作。至于前一种方式，因为关系型数据库并不能很好地支持层次、顺序、包含等在结构化置标语言中十分本质的关系，所以在开发中也仍有很多问题要解决。

面向对象数据库源于计算机编程语言中的面向对象技术。同以往的结构化编程语言相比，面向对象技术提供了一种同现实世界更加贴切的表达方式，它利用封装技术将属性和方法集成于对象之中，并且借助继承和派生的概念将对象及其子对象紧紧联系在一起。面向对象技术体现了人类对生存于其中的世界的认知过程，而同数据库技术的结合，则又是一种在计算机应用领域的进步。面向对象数据库管理系统（OODBMS）使得文本、图像、视频和空间数据可以存储在数据库中，不过与关系数据库不同：在关系数据库中，数据仅仅是数据，它不包含层次结构信息；而面向对象数据库可以将数据视为对象，数据是作为一个整体，包含了属性和方法，并能体现数据间的继承关系。下图示出了面向对象数据库管理系统概念。

从理论上看，相比关系数据库而言，面向对象数据库具有技术新、效率高的优点。为此，曾经有人大胆预言，面向对象数据库体系结构将迅速取代传统的关系数据库体系结构。但是，事实证明，这一预言是错误的，真正的面向对象数据库系统还有很长的路要走。这其中的原因是多方面的，比如面向对象技术较为复杂、面向对象数据库技术的工业化成熟程度不够高等等。作为一种折衷，利用现有的优势、改造关系数据库并融入面向对象技术，即所谓的对象-关系数据库，则不失为上策。如今，IBM、Oracle、Informix等知名厂商已经宣称其数据库产品支持面向对象技术。

但是，XML的出现给面向对象数据库注入了新的生机和动力。前面我们提到，当XML同关系数据库相结合时，一般需要将XML文档按元素层次结构拆分后依次存入数据库中的相应字段。显然，这样一来，XML文档的整体性将受到破坏，除非有一个预先设定的小程序对数据库中数据进行整合，否则XML数据将变成一团糟。（当然，如果将数据库字段作为元素的属性看待，也许这种做法倒是可行的。可聪明的读者一眼就能看出，这种假设的前提是，该XML文档将只能表达简单的结构，再复杂一点就不行了。实际上，这种情况简直是难以想象的，因为现实世界是纷繁复杂的。）而面向对象数据库就不同了，因为此时，XML将不再被拆分而是被描述成一个对象存入数据库，其优点显而易见，XML数据的结构和语义信息可以完整地保留下来。XML及其在各个领域的应用前景使得面向对象数据库重新受到广泛重视，一些针对XML的面向对象数据库纷纷推出，例如：Xhive和XML Repository就是很好的例子。著名的Object Design公司也调整策略，将其面向对象数据库产品ObjectStore融入XML Server体系之中。值得一提的是，他们还将公司更名为eXcelon，以便更好地体现该公司的战略部署。

前面讨论了关系数据库、面向对象数据库以及它们所提供的对XML的支持，那么，究竟什么样的数据库才能称得上是XML数据库呢？我们认为，一个基于XML的数据库系统应该具备以下特征：

1. 能够根据文档类型定义(DTD或Schema)确定数据库的模式。也就是说，能够按照DTD或Schema来定义数据库，而无须再进行数据库的设计，能够按照DTD或Schema的层次结构来进行基于XML语法的定位和查询。通过元素名字和属性来查询和定位元素。
2. 支持DOM和SAX，可以进行事件驱动的XML处理。
3. 内置数据处理语言模块（XML语法分析器），能够进行XML文档数据的语法分析，同时对数据库中的元素进行直接的定位操作。
4. 提供标准的XML查询语言。通过套用一定的样式模式，输出多种格式的XML文档。
5. 能够处理大型数据集合，能够对置标文本的结构和内容进行索引。
6. 提供开发工具包，支持DOM、SAX、Java、Script语言等。
7. 提供一定的机制保证数据的一致性。如通过行级或页级共享锁、排他锁对数据加锁，满足用户对数据进行并发读写时数据的有效性。
8. 支持OLAP和数据仓库等高级应用。

根据上面提到的特征，一个标准的XML数据库管理系统应由下列几个模块组成：

1. 数据编辑模块--XML编辑器

能够以图形化、交互式界面方式对XML文件实例进行编辑，方便用户对XML文件的编辑、修改等操作。另外，该编辑器还应提供同后端数据库的接口，使得用户能够方便地从数据库中调出已有的资料进行利用。编辑器应该有良好的用户交互界面，多文档编辑，能够支持通用的文件类型，支持CSS和XSL，能够按照样式文件进行结构化文档的显示，查看源文件、DTD、Schema，能够进行结构导航。EditML技术公司开发的一种开放软件EditML就是很好的例子。

2. 语法分析模块--XML Parser

能够对XML文本进行语法分析，能够进行元素的定位和查询。语法分析模块负责对DTD文件、XML文件的语法分析，能对错误进行定位并提出建设性的改进意见；语法分析模块还负责生成XML文件的结构树，并能从结构树到文件实例的映射；负责按照文件类型定义生成数据库的模式，包括数据库字段的定义、可能的数据类型、存储量的估计等等。

3. 数据库的管理模块--DB Manager

提供图形化的数据库管理功能，包括对XML文本资料的存贮、索引、检索等功能，提供数据的备份、复制等功能；能够对不同的文件类型定义的置标文本进行分类存贮。其他的管理功能包括多用户并发共享数据库的加锁机制等等。

4. 索引和检索模块

一个基于数据库的搜索引擎，它应该能够理解结构化置标树结构，提供全文索引和区域索引，对元素和属性进行索引，对结构和内容进行索引，能够按照元素和属性定位并检索元素。

5. 数据库接口模块

提供数据库系统的应用程序接口模块(API)，包括数据库本身的编程接口以及XML数据库的标准查询接口。这是对一个开放型系统的最低要求。

通常，XML在数据库中的应用模型需要借助三层架构来实现。在这种模式下，一般会有一个代理程序运行于中间层，通过它来访问数据库管理系统中的数据和输出XML文档。想必大家都对建筑工地上运载材料的吊车不太陌生吧？通过吊车，工人们就可以将地面的建筑材料运上高高的建筑操作平台；同时，也可以将平台上的废料送至地面，大大提高了劳动效率。代理程序也起着同样的作用，实际上，它是一种在客户端桌面应用层与底层数据层之间传递数据的工具。利用CSS或XSL技术，XML可以实现基于Web浏览器的多样式可视化显示。另外，这种代理程序还可以进行双向的基于事件的数据更新，也就是说，客户端的数据变化（如数据的插入、删除、修改等）可以通过代理程序反映到底层数据库，而数据库的更新也能够通知到客户端。表面上看，这种机制同传统的三层架构没有什么区别，但实际上是不同的，因为此时在传输过程中的数据都是已经XML化了的。

微软在其Windows分布式Internet应用（即Windows DNA）架构中集成了XML技术。通过中间层的代理程序，可获取的数据来源可以不必局限于某台固定的数据库服务器，而可以是分布于企业内，甚至于遍及全球各地的数据库服务器。另外，借助于XML Schema，开发者就能更为精确地描述和交换数据，因而大大地提高这种应用的效率。

XML提供了一种连接关系数据库和面向对象数据库以及其他数据库管理系统之间的纽带，如下图所示。XML文档本身是一种由若干节点组成的结构，这种特点使得数据更适宜于用面向对象格式来存储，同时也有利于面向对象语言（C++、Java等）调用XML编程接口访问XML节点。关系数据库和面向对象数据库首先需要将数据从数据库中提取出来，经过转换为或直接以XML数据形式发布到网上（局域网或Internet网），然后相互交换数据，经应用层系统处理后再转存入库。

开发一个访问数据库的XML应用系统需要同时借助XML编程接口和数据库编程接口，前者用于对XML文档的解析、定位和查询，所需技术包括DOM和SAX；后者则是用于访问数据库，如数据库中数据的更新和检索等等，需要利用的技术有ODBC、JDBC、ADO等。

另外，XML文档的模式（如DTD和Schema）以及数据库的模式对于开发此类应用也是必不可少的。由于它们均可自定义数据类型，因此可以通过信息的封装来简化程序的设计。对于数据库来讲，它可以利用CREATE TYPE命令来定义对象类型。下面的示例展示了如何在数据库中定义对象类型，本例以Oracle 8i为数据库平台。

下面再给出XML Schema的相应描述。

由以上例子可以看出，“联系人”对象中包含了“姓名”、“ID”、“公司”、“EMAIL”四个元素。

到目前为止，已有大量关于XML的数据交换技术和应用面世。其中，有的只是在现有技术的基础上扩展XML支持，有的属于XML中间件产品，还有的是比较完整的XML应用。它们大多数都提供了对数据库的支持，这恰恰从一个侧面反映出XML与数据库的密切关系以及基于XML数据库应用的潜力。不同的编程语言和脚本语言需要不同的SQL API和XML语法分析器组合。例如，对于一个C++程序员来说，编写一套访问数据库的XML应用程序可能需要利用ODBC和C++ XML语法分析器；而对于一个Java程序员来说，可能只需要JDBC和Java XML语法分析器就够了；更为特殊地，如果你对微软的Visual Basic和VBScript脚本语言比较熟，那么很有可能你会用它们来开发XML应用，此时，你只要再学习一下ADO，然后借助微软的XML语法分析器进行编程（注：微软在其浏览器产品IE5.0中内置此语法分析器msxml.dll）。

下面我们就多花一些笔墨来对各种XML数据交换技术及其应用进行一些分析，其中还会有重点地给出一些典型示例。首先要讲解的是大名鼎鼎的ADO控件技术。

说到ADO就不得不先提一下ASP。ASP（Active Server Pages）是一种在服务器端解释执行的脚本技术，主要用于基于Web应用，如动态网页的Web浏览等等。它是由微软公司开发的，最早出现于IIS 3.0。ASP通过在HTML页面中嵌入脚本语句，并结合ActiveX控件技术（如ADO、CDONT等），从而建立页面丰富、动态、交互而且高效的WEB服务器应用程序。ASP支持的脚本语言有两种，即VBScript和Jscript，缺省为VBScript。ASP的工作原理是：当客户端浏览器访问Web服务器ASP文件时，服务器根据被访问文件的扩展名(.asp)识别出其类型从而启动该ASP解析器，首先服务器会遍历文件的全文，当遇到嵌入的服务器端脚本语句时就执行相应脚本（可以是启动计数或者查询数据库等等）并将返回结果按指定方式送回原处，脚本处理完毕后将生成的HTML页面文档返回至客户端，整个过程结束。

虽然ASP并不是专门为XML量身定做的，但由于XML的可扩展性以及ASP自身的结构特性，使其又可以同XML相结合，从而实现利用ASP技术进行XML数据交换。下面我们将用一个具体示例，演示如何利用ASP进行XML数据交换。在本例中，运用了ADO控件来访问关系数据库并输出XML文档，另外还采用了DOM和XSL技术，实现了XML对象的访问和XML文档输出的样式化。

我们仍用反复提及的一个例子——“客户联系信息”。这次我们是把数据放置于关系数据库中，然后运用ASP和ADO技术动态生成XML实例文档。假设我们事先已在Microsoft SQL Server数据库CLINETS中创建了一个数据表--clientList，其数据结构如下表所示：

假设现在数据库中已经存了如下记录：

下面开始我们的编程之旅。首先是要创建一个数据源，数据源（ODBC Source）实际上是定义数据来源，也就是说用来告诉程序数据的出处。有一点需要注意，数据源的创建要在服务器端进行，因为ASP本身就是在服务器端运行的。其实要做的很简单：打开控制面板，鼠标双击"ODBC数据源"，添加数据源，选择"SQL Server"，分别配置服务器名（CLIENTS所在服务器）、数据库名（CLIENTS）、数据源名称（此处定为clientList）、用户名（sa）、用户口令（空），数据源就配置好了。下面来编写相应的代码，代码将通过调用XML DOM动态生成XML结构，然后借助ADO访问数据库动态填充XML内容。

运行该ASP，将生成下面的XML文档。

通过调用XML DOM动态生成XML文档似乎有些繁琐，下面再看一段代码，这段代码是根据前面所描述的DTD(Schema)规则来生成最终的XML实例文档，也即，最终文档的结构是由程序代码来控制的。

运行该ASP，将直接在浏览器显示XML文档，内容同前面得到的结果相同。

在上面的示例中，我们看到的是如何通过自定义文档结构生成XML实例文档。显然，这种方案存在一个前提，那就是，开发者必须了解文档结构，并且通过编程严格控制输出文档的格式。但细心的读者可能会产生疑问：既然数据已经存储在数据库中，又何必大费周折重新定义一遍文档结构呢？XML的自描述性何在？为了解决这个问题，微软将其ADO技术进行了扩展以提供对XML的更大支持，结果是可以根据数据库表的内在结构直接输出XML文档，文档的格式将符合默认的DTD定义。下面是一个用Visual Basic 6.0编写的实例：

下面给出的是该程序执行后生成的XML文档--output.xml。通过分析，可以发现，它实际上是一个内嵌XML Schema的XML实例文档。该实例文档的主元素是<rs:data>，命名空间rs由xmlns:rs=’urn:schemas-microsoft-com:rowset’定义；数据库查询返回的每一条记录都作为<rs:data>的一个子元素，用<z:row>表示。<z:row>子元素实际上是空元素，信息均以属性的方式体现，属性来自于返回的数据库字段。内嵌的Schema部分<s:Schema id=’RowsetSchema’>定义了元素<row>的组织结构和规则。

ADO提供了文档保存功能，通过它，ASP可以将数据库返回结果集保存至XML文件，这些XML文件经由XSL样式化后可以在浏览器直接显示，也可以传输至其他应用系统供再次利用。另外，值得一提的是，微软在其ADO2.5和IIS5.0中又增加了更高级的支持，即，可以将数据库返回的结果直接转换为XML在浏览器中显示，而不必先保存至文件。下面的实例片段有力地说明了这一点：

尽管XML在多数情况下可以很好地描述数据，但是开发者有时却不得不使用CGI来进行浏览器和服务器之间的数据交换。这是，问题就出现了。从信息交换的角度来讲，虽然CGI是完全能够满足要求的，但是，当CGI同XML一起使用时就会掩盖XML自身的一些优点，从而使得XML在信息交换方面的优势无处找寻。

不过，微软对此已有自己的解决方案，它提供了一种更加有效的方法来传输XML——XMLHTTP。XMLHTTP是微软的又一项基于XML的数据交换技术，主要用于在服务器与客户端交换XML数据。该技术源于微软在其XML DOM实现中引入的一个重要对象——XMLHttpRequest（Microsoft.XMLHTTP），它可以为客户端提供同HTTP服务器通讯的协议支持。简而言之，它允许你打开一个到服务器上的HTTP连接，然后发送和接受数据，并且利用Microsoft XML DOM对返回数据进行解析。

使用XMLHTTP对象通常是进行XML数据交换，但也并不局限于此，其他格式的数据也是允许的。另外，通过同XSL相结合，XMLHTTP提供了一种便捷方式发送结构化查询字串到服务器，然后将返回结果在客户端以多种方式显示。这种交换类型的标准模式是客户端发送一个XML格式的文本字符串到服务器，然后服务器将这个字符串装载入一个XML DOM对象中并进行解析，然后返回一段 HTML给客户端，或者是另外一段XML代码给客户端让客户端的浏览器自己解释。在这种方式下，对于信息的传递是非常有效的，尤其是当使用DHTML进行页面的动态显示时。

下面的一个例子描述了XMLHTTP的上述功能。假定我们在服务器端已有一个XML实例文档client.xml。

下面的代码片段描述的是客户端发出请求界面，首先需要输入待查联系人的姓名和公司，点击"查询"按钮后，程序执行查询函数。该函数首先创建一个XMLHTTP对象——xmlHTTP，和一个XML DOM对象——client，前者用于向服务器（http://localhost/Query.asp）发送XML数据（xmlHTTP.send(template.XMLDocument)）和接收XML数据（xmlHTTP.responseXML.xml）。

下面的代码片段(Query.asp)描述的则是服务器端的处理流程，首先创建两个XML DOM对象，一个对应于XML文件client.xml（xmlClient.load(Server.MapPath("client.xml"))），另一个对应于是客户端传送的XML数据（queryClient.load(Request)）。然后程序根据传送的XML数据构建XSL查询参数并进行节点定位，如果匹配成功，返回客户端查询到的XML数据；否则返回"<result>查无此人!</result>"的XML数据。

DB2XML是一种将数据从关系数据库转换成XML文档的工具，它提供了一组Java类，是由100%纯Java编写的。DB2XML可以完成下面三种功能：

• 将数据库查询结果或整个数据库转换成XML文档或者HTML文档（利用XSLT）；
• 提供数据的属性描述；
• 支持同XSLT样式单处理器的方便集成。

DB2XML可以作为一种工具通过图形界面或以命令行方式单独使用；也可以作为servlet来使用，在这种方式下，它可以动态输出XML文档；另外，DB2XML还可以以API的方式调用，这对程序员来说尤其具有吸引力。从根本上看，DB2XML是一种样式驱动的应用，其输出的XML文档实际上是一组表格，而具体内容取决于用户输入的SELECT命令语句。另外，还可以为该XML文档指定标记名称以及是否包含数据库元数据。DB2XML生成的XML文档是通过两种结构方式来表达的，一种是标准的W3C DOM对象，另一种是利用DB2XML特定的数据结构。但是，不论采用哪种方式，都能够通过数据流或单字节数组进行访问。

DB2XML是通过JDBC对数据库进行存取访问的，其应用开发需要JDK 1.1x以及提供JDBC驱动支持的数据库（如Oracle、Microsoft Access、Microsoft SQL Server、InstantDB、MySQL）。

在DB2XML的开发中，一个重要的类是JDBCXML。下面给出一个典型示例，是一个关于PermissionFrame的GUI应用：

相关网址：http://www.informatik.fh-wiesbaden.de/~turau/DB2XML/index.html

ODBC2XML是由Intelligent Systems Research开发的共享软件，它实际上是一个Windows动态库DLL，通过它，可以将数据从数据库中提取出来并转换成XML文档。该软件属于模板驱动，也就是说，将SELECT语句作为处理指令嵌入到模板中。ODBC2XML在使用时相当灵活，内嵌查询的返回结果可以直接作为元素或属性存在，甚至可以再次作为其他查询的参数，从而产生嵌套的XML文档。

相关网址：http://members.xoom.com/gvaughan/odbc2xml.htm

到目前为止，我们都是在孤立地讲XML、讨论和XML相关的协议和工具，教会大家如何直接写一个XML文件，如何利用浏览器分析它浏览它。但实际上，同HTML一样，XML有时是动态生成的，需要我们编写一段代码一个脚本，作为一个“局外人”间接地去创建、访问和操作一个XML文件。还有些时候，我们所开发的应用程序需要能够读懂别人写的XML文件，从中提取我们所需要的信息。在以上这些情况下，我们都需要一个XML接口，这个接口是善意友好的，我们以它为媒，将我们的应用程序与XML文档结合在一起。在这一章里，我们就来介绍由W3C和XML_DEV邮件列表成员分别提出的两个标准应用程序接口：DOM和SAX。

实际上，XML文档就是一个文本文件，因此在我们需要访问文档中的内容时，必须首先书写一个能够识别XML文档信息的文本文件阅读器，也就是我们通常所说的XML语法分析器，由它来帮助我们解释XML文档并提取其中的内容。这就要求每个应用XML的人都要自己去处理XML的语法细节，显然是一项非常耗时的工作。更糟糕的是，如果需要在不同的应用程序或开发环境中访问XML文档中的数据，这样的分析器代码就要被重写多次。

或许您会觉得这难不倒您：把XML分析器做成一个DLL不就可以解决代码重写的问题了吗？回答当然是肯定的。不过，每一个XML分析器的DLL必然有自己的接口，我们正是通过这个接口来访问并处理XML文档中的数据的。但如果各种分析器的接口都不相同，那么我们的开发就必须是针对某一个XML分析器的，要是想换用另外一个分析器，那么非常抱歉，程序不得不重新改写。因此，有了DLL有了接口还远远不够，我们还需要一个善意友好的接口，也就是一个统一的接口。要真正实现代码的重用，就必须解决DLL的接口标准问题。

我们知道，数据库有标准的ODBC/JDBC这样的接口规范。在它的帮助下，我们编写数据库应用程序的时候只要针对于接口即可，可以不管后台的数据库系统究竟是ORACLE还是SYBASE，是DB2还是SQL Server，这给应用程序的开发带来了很大的便利。同样的道理，在我们做XML的应用开发时，一个统一的XML数据接口也是必需的。

W3C意识到了上述问题的存在，于是制定了一套书写XML分析器的标准接口规范--DOM。除此之外，XML_DEV邮件列表中的成员根据应用的需求也自发地定义了一套对XML文档进行操作的接口规范--SAX。这两种接口规范各有侧重，互有长短，应用都比较广泛。

下面，我们给出DOM和SAX在应用程序开发过程中所处地位的示意图。从图中可以看出，应用程序不是直接对XML文档进行操作的，而是首先由XML分析器对XML文档进行分析，然后，应用程序通过XML分析器所提供的DOM接口或SAX接口对分析结果进行操作，从而间接地实现了对XML文档的访问。

如前所述，之所以要制定一个接口标准，是为了给XML应用程序的开发带来方便，使得应用程序可以根据需要随时选择、更换合适的分析器，同时又无须对程序本身再做大的改动。那么读者可能会问，既然接口需要统一，为什么现在还有两个接口标准共存呢？这两个标准之间又存在什么关系呢？

事实上，DOM和SAX两个接口标准之所以能够并存，就是因为它们所要实现的目标不同。DOM和SAX分析器在接口实现过程中分别侧重于不同的方面，二者各有长短，分别满足了不同的应用需求。在进行横向比较之前，我们先来分别简要介绍一下这两个标准。

DOM

DOM的全称是Document Object Model，也即文档对象模型。在应用程序中，基于DOM的XML分析器将一个XML文档转换成一个对象模型的集合（通常称DOM树），应用程序正是通过对这个对象模型的操作，来实现对XML文档数据的操作。通过DOM接口，应用程序可以在任何时候访问XML文档中的任何一部分数据，因此，这种利用DOM接口的机制也被称作随机访问机制。

DOM接口提供了一种通过分层对象模型来访问XML文档信息的方式，这些分层对象模型依据XML的文档结构形成了一棵节点树。无论XML文档中所描述的是什么类型的信息，即便是制表数据、项目列表或一个文档，利用DOM所生成的模型都是节点树的形式。也就是说，DOM强制使用树模型来访问XML文档中的信息。由于XML本质上就是一种分层结构，所以这种描述方法是相当有效的。

SAX

SAX的全称是Simple APIs for XML，也即XML简单应用程序接口。与DOM不同，SAX提供的访问模式是一种顺序模式，这是一种快速读写XML数据的方式。当使用SAX分析器对XML文档进行分析时，会触发一系列事件，并激活相应的事件处理函数，应用程序通过这些事件处理函数实现对XML文档的访问，因而SAX接口也被称作事件驱动接口。

DOM树所提供的随机访问方式给应用程序的开发带来了很大的灵活性，它可以任意地控制整个XML文档中的内容。然而，由于DOM分析器把整个XML文档转化成DOM树放在了内存中，因此，当文档比较大或者结构比较复杂时，对内存的需求就比较高。而且，对于结构复杂的树的遍历也是一项耗时的操作。所以，DOM分析器对机器性能的要求比较高，实现效率不十分理想。不过，由于DOM分析器所采用的树结构的思想与XML文档的结构相吻合，同时鉴于随机访问所带来的方便，因此，DOM分析器还是有很广泛的使用价值的。

SAX分析器在对XML文档进行分析时，触发了一系列的事件，由于事件触发本身是有时序性的，因此，SAX提供的是一种顺序访问机制，对于已经分析过的部分，不能再倒回去重新处理。SAX之所以被叫做"简单"应用程序接口，是因为SAX分析器只做了一些简单的工作，大部分工作还要由应用程序自己去做。也就是说，SAX分析器在实现时，它只是顺序地检查XML文档中的字节流，判断当前字节是XML语法中的哪一部分、是否符合XML语法，然后再触发相应的事件，而事件处理函数本身则要由应用程序自己来实现。同DOM分析器相比，SAX分析器缺乏灵活性。然而，由于SAX分析器实现简单，对内存要求比较低，因此实现效率比较高，对于那些只需要访问XML文档中的数据而不对文档进行更改的应用程序来说，SAX分析器更为合适。

综上所述，无论是DOM接口还是SAX接口，都各自有其优缺点。也正是如此，它们将长期并存下去，在不同的应用中发挥不同的作用。

对于XML应用开发来说，DOM就是一个对象化的XML数据接口，一个与语言无关、与平台无关的标准接口规范。它定义了HTML文档和XML文档的逻辑结构，给出了一种访问和处理HTML文档和XML文档的方法。利用DOM，程序开发人员可以动态地创建文档，遍历文档结构，添加、修改、删除文档内容，改变文档的显示方式等等。可以这样说，文档代表的是数据，而DOM则代表了如何去处理这些数据。无论是在浏览器里还是在浏览器外，无论是在服务器上还是在客户端，只要有用到XML的地方，就会碰到对DOM的应用。

作为W3C的标准接口规范，目前，DOM由三部分组成，包括：核心（core）、HTML和XML。核心部分是结构化文档比较底层对象的集合，这一部分所定义的对象已经完全可以表达出任何HTML和XML文档中的数据了。HTML接口和XML接口两部分则是专为操作具体的HTML文档和XML文档所提供的高级接口，使对这两类文件的操作更加方便。

目前，DOM有两个版本，一个是由W3C于1998年8月18日通过的DOM Level 1，另一个则是正在制定过程中的DOM Level 2，W3C已于2000年3月7日通过了DOM Level 2的候选推荐版本。

前面我们讲过，DOM为我们提供的访问XML文档信息的媒介是一种分层对象模型，而这个层次的结构，则是一棵根据XML文档生成的节点树。

一个XML分析器，在对XML文档进行分析之后，不管这个文档有多简单或者多复杂，其中的信息都会被转化成一棵对象节点树。在这棵节点树中，有一个根节点--Document节点，所有其他的节点都是根节点的后代节点。节点树生成之后，就可以通过DOM接口访问、修改、添加、删除、创建树中的节点和内容。

以我们非常熟悉的客户联系信息的例子来说明，下面给出一个XML文档片段：

用DOM来表示这段文档，如图所示：

在这棵文档对象树中，文档中所有的内容都是用节点来表示的。一个节点又可以包含其他节点，节点本身还可能包含一些信息，例如节点的名字、节点值、节点类型等。文档中的根实际上也是一个元素，之所以要把它单独列出来，是因为在XML文档中，所有其他元素都是根元素的后代元素，而且根元素是唯一的，具有其他元素所不具有的某些特征。

这个例子比较简单，事实上，DOM中还包含注释、处理指令、文档类型、实体、实体引用、命名空间、事件、样式单等多种对象模型。

文档对象模型利用对象来把文档模型化，这些模型不仅描述了文档的结构，还定义了模型中对象的行为。换句话说，在上面给出的例子里，图中的节点不是数据结构，而是对象，对象中包含方法和属性。在DOM中，对象模型要实现：

• 用来表示、操作文档的接口
• 接口的行为和属性
• 接口之间的关系以及互操作
  

在DOM接口规范中，有四个基本的接口：Document，Node，NodeList以及NamedNodeMap。在这四个基本接口中，Document接口是对文档进行操作的入口，它是从Node接口继承过来的。Node接口是其他大多数接口的父类，象Documet，Element，Attribute，Text，Comment等接口都是从Node接口继承过来的。NodeList接口是一个节点的集合，它包含了某个节点中的所有子节点。NamedNodeMap接口也是一个节点的集合，通过该接口，可以建立节点名和节点之间的一一映射关系，从而利用节点名可以直接访问特定的节点。下面将对这四个接口分别做一些简单的介绍。

1. Document接口

Document接口代表了整个XML/HTML文档，因此，它是整棵文档树的根，提供了对文档中的数据进行访问和操作的入口。

由于元素、文本节点、注释、处理指令等都不能脱离文档的上下文关系而独立存在，所以在Document接口提供了创建其他节点对象的方法，通过该方法创建的节点对象都有一个ownerDocument属性，用来表明当前节点是由谁所创建的以及节点同Document之间的联系。

在DOM树中，Document接口同其他接口之间的关系如下图所示：

由图可以看出，Document节点是DOM树中的根节点，也即对XML文档进行操作的入口节点。通过Docuemt节点，可以访问到文档中的其他节点，如处理指令、注释、文档类型以及XML文档的根元素节点等等。另外，从上图我们还可以看出，在一棵DOM树中，Document节点可以包含多个处理指令、多个注释作为其子节点，而文档类型节点和XML文档根元素节点都是唯一的。

关于Document接口的IDL（Interface Definition Language接口定义语言）定义和其中一些比较常用的属性和方法的详细介绍在许多参考书都可以找到，我们将在后面结合实际例子给予介绍。

2. Node接口

Node接口在整个DOM树中具有举足轻重的地位，DOM接口中有很大一部分接口是从Node接口继承过来的，例如，Element、Attr、CDATASection等接口，都是从Node继承过来的。在DOM树中，Node接口代表了树中的一个节点。一个典型的Node接口如下图所示：

如图所示，Node接口提供了访问DOM树中元素内容与信息的途径，并给出了对DOM树中的元素进行遍历的支持。

同样，我们将在后面结合实际例子详细说明Node接口的具体使用方法。

3. NodeList接口

NodeList接口提供了对节点集合的抽象定义，它并不包含如何实现这个节点集的定义。NodeList用于表示有顺序关系的一组节点，比如某个节点的子节点序列。另外，它还出现在一些方法的返回值中，例如GetNodeByName。

在DOM中，NodeList的对象是"live"的，换句话说，对文档的改变，会直接反映到相关的NodeList对象中。例如，如果通过DOM获得一个NodeList对象，该对象中包含了某个Element节点的所有子节点的集合，那么，当再通过DOM对Element节点进行操作（添加、删除、改动节点中的子节点）时，这些改变将会自动地反映到NodeList对象中，而不需DOM应用程序再做其他额外的操作。

NodeList中的每个item都可以通过一个索引来访问，该索引值从0开始。

4. NamedNodeMap接口

实现了NamedNodeMap接口的对象中包含了可以通过名字来访问的一组节点的集合。不过注意，NamedNodeMap并不是从NodeList继承过来的，它所包含的节点集中的节点是无序的。尽管这些节点也可以通过索引来进行访问，但这只是提供了枚举NamedNodeMap中所包含节点的一种简单方法，并不表明在DOM规范中为NamedNodeMap中的节点规定了一种排列顺序。

NamedNodeMap表示的是一组节点和其唯一名字的一一对应关系，这个接口主要用在属性节点的表示上。
与NodeList相同，在DOM中，NamedNodeMap对象也是"live"的。

通过上面的介绍，我们已经对DOM接口有了部分了解，那么，这些接口以及接口中的属性和方法又应该如何使用呢？这正是接下来所要讲述的内容。

如前所述，利用DOM，程序开发人员可以动态地创建文档，遍历文档结构，添加、修改、删除文档内容等等。在本节中，我们将通过微软的XML分析器msxml，对DOM接口的这些应用做一详细的介绍。

首先，我们来讲一下一切操作的基础——创建Document对象。通过创建Document对象，应用程序或者脚本就得到了对XML文档进行操作的入口。下面给出了使用不同的编程语言创建Document对象的范例。

为了描述简单起见，在后面的例子中将只采用VBScript语言作为范例书写语言。

在Document对象创建之后，我们就得到了对文档进行操作的入口，那么，创建的这个文档对象是如何同实际的XML文档关联在一起的呢？说来可笑，在W3C的DOM接口规范中，没有任何一个地方定义了DOM中的接口对象同实际文档相关联的方法。因此，不同的XML分析器所提供的加载XML文档的方法也不尽相同。在微软的msxml中，提供了一个load方法来加载XML文档，建立DOM树同XML文档之间的关联。

依旧以联系人列表信息的XML文档.xml为例，可通过下述方式来加载文档：

XML文档被加载后，就在内存中形成了一棵DOM树，如图9-6所示：

现在，我们已经可以通过DOM来创建XML文档对象，并加载XML文档了。对于已经加载的文档，我们要从文档中获取所需要的内容，这就要求能够通过DOM树来访问树中的任何一个节点，也就是对DOM树的遍历。下面我们依旧以client.xml为例，通过几个实例来说明如何遍历DOM树中的节点。

首先，我们要获取XML文档的根元素节点，用VBScript语言描述这个操作如下：

该语句的实际含义如下图黄色箭头所示。

在得到了文档的根元素节点之后，我们又将如何访问其他元素呢？以文档中的第二个person元素为例，对该元素节点以及其子节点的访问可以通过下面的方式来实现：

上述访问语句执行后，theName的值是"李四"。下图黄色箭头给出了这一访问过程的示意：

在上面的代码中，root是文档的根元素节点addressbook节点，personNode和nameNode都是元素类型的节点，textNode是TEXT类型的节点，theName是一个字符串。

childNodes是NodeList类型的属性，item是NodeList接口中Node类型的属性，通过item可以访问NodeList节点集合中的任意节点（这儿有一点需要注意，当我们要访问根元素节点addressbook的第二个person子节点personNode时，我们用的索引参数是"1"，这是因为item中的索引参数是从0开始的，如果我们要访问节点集合中的第一个节点，则应该用item(0)来表示）。

在DOM规范中，要访问元素节点的文本内容，需要先得到元素节点的TEXT子节点，再通过TEXT节点的属性获取文本内容。微软在实现DOM接口时对DOM进行了部分扩展，可以通过元素类型节点的text属性直接获得元素中的文本内容。具体实用说明可以参考微软msdn中的帮助。

上面的例子给出了如何访问DOM树中的元素节点，对于DOM树中的属性节点，访问方法略有不同，可以通过下面的语句来实现：

上述访问语句执行后，attrContent的值是"male"。下图用黄色箭头标出了这一访问的过程。

在上面的代码中，attr是属性类型的节点，attributes是NamedNodeMap类型的属性，getNamedItem是NamedNodeMap接口中的方法。属性的内容可以通过属性节点的nodeValue来获得。

目前，我们已经能够通过DOM获取XML文档中的信息了。如前所述，通过DOM还可以动态地更改XML文档中的内容。下面我们仍旧使用上面的client.xml文档，通过实例来说明如何更改XML文档中的内容。

假如我们希望在addressbook.xml中，给第一个person元素增添一个字符串为"北大方正"的company元素，实现这一添加元素操作的语句如下：

下面给出了添加元素的操作示意图：

现在，我们再把前一小节添加的元素删除，可通过下面的代码实现这一目的：

其中，oldNode中存放的是已被删除的节点。在删除某个节点时，以该节点为根的子树将整个被删除，因此得到的结果DOM树恢复原状。

8.3.2.4 实现DocumentHandler接口     DocumentHandler接口是我们要用到的一个最重要的JAXP接口，在该接口中，需要一系列的方法，这些方法是SAX分析器在对XML文档进行分析时遇到不同的分析事件所激发的相应处理。目前，主要用到五个方法：startDocument，endDocument，startElement，endElement，以及characters，下面黑体部分所标注的代码就是用来响应这五种事件处理的： ... static private Writer out; public void startDocument () throws SAXException { } public void endDocument () throws SAXException { } public void startElement (String name, AttributeList attrs) throws SAXException { } public void endElement (String name) throws SAXException { } public void characters (char buf [], int offset, int len) throws SAXException { } ... 当分析器遇到一个起始标记或者一个结束标记时，标记名就作为一个字符串变量传递给方法startElement和endElement。另外，当遇到起始标记时，起始标记所代表的元素的所有的属性都以AttributeList的形式传递给startElement方法。在一个元素内的字符以一个字符数组的形式传递给characters方法，在characters方法中还有另外两个参数，其中一个代表字符数组的长度，也即字符的个数，另一个参数代表元素内的第一个字符在字符数组中的偏移。 对于下面所示的XML文档： <?xml version = "1.0"?> <addressbook> <person>   <lastname>Idris</lastname>   <firstname>Nazmul</firstname>   <company>The Bean Factory, LLC.</company>   <email>xml@beanfactory.com</email> </person> </addressbook> 当对它利用SAX分析器中的DocumentHandler接口中的方法进行分析时，方法的调用时序如图所示： 　 8.3.2.5 输出异常     每个DocumentHandler接口的方法都会产生SAXExceptions异常，但不会产生写文件时可能发生的IOExceptions异常。可是，由于SAXException可以封装其他异常，因此可以通过一个自定义的方法来处理异常。下面代码的黑体部分就是用来处理异常的函数： public void characters (char buf [], int offset, int Len) throws SAXException{ } private void emit (String s) throws SAXException{ try {   out.write (s);   out.flush (); } catch (IOException e) {   throw new SAXException ("I/O error", e); } } ... 当emit方法被调用时，所有输入/输出错误都被封装在了SAXException中，并由SAX分析器来处理SAXException异常。 8.3.2.6 简单格式化输出     在对XML文档进行实际的处理之前，我们还需要做最后一件事情——写一个简单的换行函数nl，使输出文档不至于都输出在同一行上，以增加输出文档的可读性，如下面代码中的黑体所示： private void emit (String s) { ... } private void nl () throws SAXException { String lineEnd = System.getProperty("line.separator"); try {   out.write (lineEnd); } catch (IOException e) {   throw new SAXException ("I/O error", e); } } 　 8.3.2.7 处理文档事件       在"实现DocumentHandler接口"一节中，我们定义了五个文档事件处理方法的框架，现在，我们来实现框架中的实际内容，如下所示： public void startDocument () throws SAXException { emit ("<?xml version= 1.0 encoding= gb2312 ?>"); nl(); } public void endDocument () throws SAXException { try {   nl();   out.flush (); } catch (IOException e) {   throw new SAXException ("I/O error", e); } } 在上面代码中，当分析器遇到文档的起始部分时，就输出XML文档声明语句。当分析器分析到文档的结束时，简单地输出一个换行，并把输出流中的内容全部输出。就文档开始与结束而言，不需要再做其他的工作。而对于元素起始与结束，所做的工作如下面代码中的黑体部分所示： public void startElement (String name, AttributeList attrs) throws SAXException { emit ("<"+name); if (attrs != null) {   for (int i = 0; i < attrs.getLength (); i++) {    emit (" ");    emit (attrs.getName(i)+"=\""+attrs.getValue (i)+"\"");   } } emit (">"); } public void endElement (String name) throws SAXException { emit ("</"+name+">"); } 通过上面的代码，可以输出所遇到的元素名称以及元素的所有属性。现在，只剩下XML文档中的文本内容没有输出了。下面代码则是characters方法的实现： public void characters (char buf [], int offset, int len) throws SAXException { String s = new String(buf, offset, len); emit (s); } 到目前为止，我们已经写完了利用SAX分析器的一个应用程序Echo.java，接下来就是编译并执行该应用程序了。 8.3.3 应用程序的编译与执行       最后，我们来说说所编写的程序的编译和执行方法。 编译应用程序 在不同的系统中，编译指令也有所不同。 Windows: javac -classpath %XML_HOME%\jaxp.jar;%XML_HOME%\parser.jar Echo.java Unix: javac -classpath ${XML_HOME}/jaxp.jar:${XML_HOME}/parser.jar Echo.java 其中 XML_HOME是安装JAXP和Project X库的路径。 jaxp.jar中包含了JAXP中所定义的APIs。 parser.jar中则包含了实现SAX和DOM APIs的接口和类。 执行应用程序 如果要执行应用程序，在不同的系统中，指令也有所不同。 Windows: java -classpath .;%XML_HOME%\jaxp.jar;%XML_HOME%\parser.jar Echo slideSample.xml 经过了编译和执行后，我们的echo.java程序就可以如愿以偿地发挥作用了。

进行完对于XML的一系列基本介绍之后，让我们来探索一些XML更深层次的技术。完成了后面三章的学习，相信您将跃升为一个XML开发高手。这一章我们首先从XML链接说起。

说起HTML，大家可能都会对它所提供的超链接功能拍手称快。的确，超链接可以说是鼓起了我们网上冲浪的风帆，它打破了传统的直线形和树形的信息组织结构，根据发散思维的特点，帮助我们利用网状的信息组织，方便地浏览我们感兴趣的内容。

了解HTML的读者都知道，在HTML中表示链接的标记是<A>，通过标记<A>，可以从一个文件链接到另一个文件，或者链接到文件的某一部分。另外，使用标记<IMG>等可以将图象直接嵌入网页。下面就是一个典型的HTML链接的例子：

HTML链接尽管定义简单，使用方便，但它也存在着明显的局限性。首先，HTML链接是单向的，它只能从链接所在的文件指向另一个文件。也就是说，我们可以通过标记<A>的href属性知道该文件的若干链接目标，但无法知道又有哪些文件链接到该文件，不知道它有哪些链接源。其次，HTML链接只能指向一个文件，在需要指定多个链接的时候，不得不使用多个<A>标记，而由于HTML是非结构化的，这些链接的关系和结构信息无法表现。第三，HTML可以链接到文件内部的某一部分，这通过在目标文件中插入命名锚（named anchor）来实现。但是，如果源文件和目标文件由不同的人员负责，甚至在不同的站点上，两个文件的协作就成为问题。

XML链接在HTML链接的功能之上又加以扩展，可以支持更为复杂的链接。通过XML链接，不仅可以在XML文件之间建立链接，而且可以建立其他类型数据之间的链接。不仅如此，XML链接还为文件内部定位提供了全新的方式，允许链接的建立者利用文件结构指定文件内部的资源片断。利用简单XML链接，可以轻松地实现HTML中的链接功能；利用扩展XML链接，可以在多个资源之间建立链接，还可以建立多向的链接；利用XPointer在一个XML文件内部的定位功能，可以利用目标文件的结构指定所链接的资源，而无需对目标文件进行任何修改；利用链接库，可以将链接从文件中分离出来，就象用XSL文件把样式转换信息从XML文件中独立出来一样，从而简化链接的管理。

XML链接规范分为三个部分：XLink语言、XPointer语言和XML Base，我们将分三节分别进行讲述。关于Xlink的讨论基于XLink语言规范2000年7月3日候选标准；有关XPointer的讨论基于XPointer语言规范2000年6月7日候选标准；有关XBase的讨论基于XBase规范2000年6月7日工作草案。当前这几个规范都不是正式标准，因此并不稳定，某些内容会随着规范的发展而变化，建议大家在具体开发时参考一下W3C公布的最新版本，XLink、XPointer和XBase规范的最新版本分别可在http://www.w3.org/TR/xlink、http://www.w3.org/TR/xptr、http://www.w3.org/TR/xmlbase处取得。

在详细介绍XML链接之前，我们先来看一个XML链接的例子：

与HTML的链接元素相比较，上面这个例子中的XML链接元素存在以下几点不同：

1. 标记名不同。上例中用的是LINK，而不是HTML中的A。事实上，XML中没有专门用于链接的标记，任意标记名的元素都可以是XML的链接元素，因此例子中的标记名LINK，完全可以换成其他的名字，而不象在HTML中那样一定要用标记<A>。
2. 使用了命名空间。上例中的第一个属性为命名空间声明，且其他属性名都有命名空间前缀。虽然可以使用自己喜欢的任何前缀代表XLink命名空间，但直接使用xlink前缀可以增加文件的可读性，因而我们更推荐这种做法。xlink前缀可以在文件的根元素中定义，也可以在使用xlink前缀的元素中定义。
3. 增加了许多与链接相关的属性。例子中除了第一个属性是命名空间声明和第三个属性与HTML相似以外，其他的属性都是新增加的。由XLink给出的全局属性一共有十个，包括type、href、role、arcrole、title、show、actuate、label、from和to。其中属性type表明了XLink元素的类型，共有六种Xlink元素，即：simple、extended、locator、arc、resource和title，但只有simple、extended 两种XLink元素才是真正的XML链接元素，而其他只用于提供各种描述链接的特性信息。处理程序正是根据type的值决定如何处理该XLink元素。需要强调的是，如果XML文件具有文件类型定义DTD，XLink的全局属性必须在DTD中定义。不过，并不是所有的XLink全局属性都必须在DTD中加以声明，可以根据需要进行裁剪，只声明使用到的属性即可。而且，将一个元素声明为链接元素并没有增加对元素的属性和内容的限制，只要元素实例符合DTD声明，仍然可以包括任意属性和内容。上例的DTD声明如下，其中属性ALT和ALIGN都与链接本身无关：

当前的主流浏览器Netscape和Internet Explorer对XLink的支持非常弱，在Netscape 6.0的预览发行版中可以发现对简单XML链接的支持，但是其支持的部分并不完全符合最新的规范；IE5.5没有提出对XLink的支持。另外，虽然现在有许多关于XLink的研究计划，但能够完整支持XLink的工具和应用还没有出现。

     简单XML链接与HTML链接非常相似，它在两个资源之间建立关联。这两个资源分别是文件中的链接元素和XLink全局属性href所指向的资源，其中链接元素为本地资源或起始资源，href所指向的资源为远程资源或目标资源。可以用简单XML链接实现HTML链接，下面示例中使用XLink实现HTML中的链接标记<A>。

可以利用上面的DTD声明，我们可以定义元素A的实例：

对照HTML中的链接的例子：

可以发现，两种写法已经非常接近，除了XML中具有xlink前缀表示XLink命名空间，其他都完全一样（这里我们假设命名空间已经在文件首部声明）。同样，它们在浏览器上的表现也应该是一样的。在上例中所链接的资源是元素A和"http://www.xlinksample.com/simplelink.xml"所指向的资源，下面是它的示意图。

同样，我们可以使用XLink实现HTML中的<IMG>标记：

当然，HTML中<IMG>标记的属性比上面列出的多一些，但是如果忽略那些不常使用的属性，使用上面的DTD声明定义实例，就可以在XML文件中嵌入图象资源。

下面，我们就来分别介绍一下简单链接中所使用到的属性。

1. 类型属性

类型（xlink:type）属性决定了链接或资源的类型，XLink处理程序根据xlink:type的值决定如何处理链接元素，但是处理程序的动作并不仅仅取决于这一个属性，它还将取决于下面将要提到的行为属性。对XLink而言，xlink:type属性可以在元素的开始标记中定义，也可以在DTD中定义缺省值，但必须使XML分析器分析到链接元素时能够得到属性xlink:type的值。xlink:type属性的取值可以是simple、extended、locator、arc、resource、title和none其中之一。

对简单XML链接，type属性固定取值为"simple"，前面定义的A标记和IMG标记都是简单XML链接的例子。

如果一个元素的xlink:type属性取值为none，那么该元素就不是一个链接元素，不具有链接意义。如果该元素还具有一些与链接相关的其他属性或子元素，这些属性和内容也将失去其链接意义。例如下例中的NOLINK元素中包括的子元素LINK，虽然指定了xlink:type为simple，但仍然不具有链接意义。

一般情况下，可以将简单XML链接元素的DTD定义如下：

但在某些情况下，元素LINK仅仅在文件某些地方作为链接元素出现，而在其他地方作为普通元素出现。此时，可以将DTD定义为：

在利用该DTD创建XML文件时，只要在需要链接元素的地方，将xlink:type属性取值为"simple"，在其他地方则取值为"none"。如果需要将链接元素改为非链接元素，只要简单地将xlink:type属性的值由"simple"改为"none"即可，反之亦然。

2. 寻址属性

XML链接元素的寻址属性是指xlink命名空间的href属性，它指定了链接的目标资源。该属性的取值是一个URI，它可以是一个文件或文件中的某一特定位置。XML链接的xlink:href属性与HTML链接的href属性基本相同，如：

在上面的三个例子中，第一个例子指定了目标资源的绝对位置，第二个例子指定了目标资源的相对位置，第三个例子指定了被链接文件中的某个具有ID属性，且取值为"zhang"的元素。对于第二种情况，XLink处理程序必须能够接收xml:base属性，指定资源相对于哪个位置，然后将xml:base与xlink:href合并得到资源的具体位置。而对于第三种情况中的文件内部定位，则由Xpointer语言定义。关于XPointer和XML Base的详细介绍，请参照本章中的XPointer和XML Base小节。

另外，简单XML链接的xlink:href属性可以不出现。此时这种链接薹ㄏ笃胀ǖ牧唇右谎せ睿匀豢梢越衅渌恚缈梢岳盟试春褪粜酝ü齒Link属性关联起来。这种用法并不常见，此时需要改写前面的DTD声明。

3. 语义属性

由于属性xlink:arcrole、xlink:role和xlink:title用于描述链接或资源，因此常称它们为语义属性。其中xlink:role属性用于机器阅读，如用于搜索引擎的“爬行”（crawler或spider）程序，而xlink:title属性则用于人工阅读。在简单 XML链接中，xlink:role和xlink:tile用于描述链接所指向的资源，在下面例子中，表示目标文件（由"http://www.xlinksample.com/students.xml"指定）具有role为"studentlist"，title为"Student List"。

属性xlink:role和xlink:title是可选的。象其他属性一样，它们可以直接用于XML文件，也可以在DTD中定义，如：

至于属性xlink:arcrole，它只能用于arc类型元素中，其作用与role类似，我们将在链接弧一节中对它作进一步介绍。

4. 行为属性

链接元素还包括两个全局属性xlink:show和xlink:actuate，用于指示在链接激活时的行为，因此称为行为属性。属性xlink:show表示链接激活时，目标资源的显示环境，如在当前窗口显示或在新的窗口中显示；而xlink:actuate表示何时激活链接，是文件加载时或用户要求时。

xlink:show属性的取值必须为new、replace、embed、other和none五个值之一。下表描述了show属性各个取值的意义，并给出了对应的HTML代码。

从表中可以看出，当属性xlink:show取值"embed"时，目标资源将直接嵌入源文件，因此起始资源常常不是完整的文件。利用目标资源的内嵌可以实现客户端的文件包含。例如：用XLink链接几个相关文件，构成一个完整的XML文件。但是，正如HTML中的IMG元素一样，目标资源的嵌入仅仅影响相关资源的显示，并不表示起始资源的转换。例如，如果目标资源是XML文件，该文件并不会作为起始资源的一个部分而被XML分析器所处理。

属性xlink:actuate表示链接的激活时间，它有四个预定义值onRequest、onLoad、other和none，actuate属性的取值必须位居其一。下面仍然以列表的形式给出各个属性的含义：

xlink:show属性和xlink:actuate属性都是可选的，它们可以直接使用，也可以在DTD声明中定义：

通过前面一节对简单XML链接的介绍，可以发现，无论是对构造链接的文件作者，还是对处理链接的应用来说，简单XML链接都与HTML中的链接十分类似。然而与HTML链接一样，简单XML链接的功能是比较有限的。为了满足复杂的需要，XML链接规范定义了扩展XML链接。通过扩展XML链接，可以在多个资源间实现多向的XML链接。

扩展XML链接元素的构造，很大程度上取决于用户，但通常都会包括一个资源集合和一个连接集合。资源集合中可以包括本地资源和远程资源，如果资源是XML链接元素的组成部分，该资源是本地资源；否则就是远程资源，如另外的XML文件或本文件的其他元素。连接集合中的各个元素表示资源集合元素间的链接。除了资源集合和连接集合外，扩展XML链接元素可以包括其他内容或标记，甚至可以包含简单XML链接或扩展XML链接作为其子元素。

扩展XML链接的xlink:type属性值固定为"extended"。它还可以具有语义属性，即前面讲到的xlink:role和xlink:title属性，其意义与前面所说的相似，只不过是用于描述整个链接。扩展XML链接包括的资源数目可以少于两个，甚至可以不包含资源。

下例是一个扩展XML链接的DTD声明，其中EXTLINK元素是一个扩展XML链接元素，它包含零到多个RESOURCE元素、LOCATOR元素和CONNECTION元素。其中RESOURCE元素表示本地资源，LOCATOR元素表示远程资源，CONNECTION元素表示这些资源间的连接。从这个声明中，我们可以对扩展链接的结构更为明了。

一般而言，扩展链接元素与其关联的资源是分离的。通过扩展链接，可以在只读资源间建立链接。有时虽然资源自身不是只读的，但是修改资源本身非常困难，而修改链接元素相对容易，或者有时资源内部无法插入链接，例如一段视频，这时都可以使用扩展链接在这些资源之间建立链接。

扩展XML链接使用特定的子元素指定本地资源，这个子元素称为本地资源元素。本地资源元素是一个将xlink:type的值取为"resource"的链接元素，而且必须作为扩展XML链接元素的直接子元素出现。

本地资源元素可以包含语义属性xlink:role和xlink:title，它用于描述该资源。同样本地资源元素的语义属性也是可选的。

另外，本地资源元素还可以包含xlink:label属性以标记该资源，该标记的值用于连接元素。xlink:label属性值可以重复，即多个资源可以具有相同的xlink:label属性值。

本地资源元素在链接属性之外，还可以包含其他的属性和内容，不过这些内容本身不具有链接意义。同样，本地资源元素也可以不包含任何内容，如果这类本地资源元素作为链接的起始资源，链接的显示将取决于处理程序。例如，由于属性xlink:title提供了该资源的描述信息，因此交互式处理程序可能会显示该属性的内容。

下例定义了一个本地资源元素：

这个例子中没有列出<RESOURCE>元素所在的上下文，其实它不应该单独存在，而应该作为一个扩展XML元素的子元素出现。

    扩展XML链接的远程资源也是通过特定的子元素来描述的，该子元素称为远程资源元素。远程资源元素的xlink:type属性的取值为"locator"，同样，远程资源元素也必须是扩展XML链接元素的直接子元素，否则也不具有链接意义。

远程资源元素具有寻址属性xlink:href和语义属性xlink:role、xlink:title。寻址属性xlink:href表示远程资源的URI，与简单XML链接中的href属性一样，它可以是一个绝对URI、相对URI或资源内部的一个具体位置。对于远程资源元素，xlink:href是必须的，通过它才能定位远程资源。语义属性xlink:role、xlink:title用于表示资源的描述信息。与本地资源元素一样，远程资源元素也可以包含xlink:label元素，其含义和要求与本地资源元素相同。

虽然包含寻址属性xlink:href，一个远程资源元素自身并不构成链接。在简单XML链接和HTML链接中，xlink:href属性表示链接元素和href指定的目标资源间之间的一个链接。但在远程资源元素中，它仅仅表示一个资源而已。也许用有向图更有助于理解上面的概念。如果将扩展XML链接表示成有向图，那么图的结点集合就是资源集合（本地资源和远程资源），而连接集合就构成图的边集合。一个远程资源元素仅仅是图的一个结点而已。

远程资源元素可以具有任何内容，一般而言，远程资源元素的内容不具有链接意义。

用xlink:type="resource"表示本地资源、用xlink:type="locator"表示远程资源有时容易令人混淆，因此《XML Bible》一书的作者Elliotte Rusty Harold建议使用xlink:type="locate"表示本地资源，而用xlink:type="remote"表示远程资源，但是在W3C规范没有采用这个建议以前，使用当前的表示法仍然是唯一的选择。

下面给出一个远程资源的例子，与前面本地资源类似，这个远程资源元素也应该作为一个扩展XML元素的子元素出现。

链接弧（arc）用于表示扩展XML链接中资源之间的连接关系，它是扩展XML链接元素的子元素，xlink:type属性值为"arc"，称之为链接弧元素。在用有向图描述扩展XML链接时，链接弧是连接资源的有向边，不过后面我们将要讲到，一个链接弧元素未必只表示一条有向边。在有向图中，随着结点个数的增加，其边的数目将指数级增加。因此在扩展XML链接中，随着资源的增加，连接的数量也会指数级增加。例如：如果一个扩展XML连接的资源由3个增加到4个，可能的连接数目将从9个上升到16个。

如果一个链接弧的起始资源在本地，而目标资源是远程的，那么这个链接弧称为出站（outbound）链接弧；反之，如果起始资源是远程的，而目标资源在本地，则称为入站（inbound）链接弧；如果起始资源和目标资源都不在本地，则称为第三方（third-party）链接弧。虽然没有作明确规定，但一般而言，一个链接一般只包含一类链接弧，因此可称为出站链接、入站链接或第三方链接。对HTML链接和简单XML链接而言，由于链接总是从链接元素到href代表的远程资源，因此都属于出站链接。扩展XML链接可以包括三种链接中的任意一种。

链接弧元素本身必须作为扩展XML链接元素的直接子元素，否则该元素将失去其链接意义。元素中可以包含任何内容，在一般情况下，这些内容不具有链接意义。链接弧元素中的属性可以有遍历属性（xlink:from和xlink:to）、行为属性（xlink:show和xlink:actuate）和语义属性（xlink:arcrole和xlink:title）。

xlink:from和xlink:to属性用于描述资源之间的连接，资源元素的标识通过其xlink:label属性识别。xlink:from定义了链接弧的起始资源，在有向图中是边的起点，xlink:to定义了链接弧的目标资源，在有向图中是边的终点。遍历属性的取值必须是资源元素（包括本地资源元素和远程资源元素）的xlink:label属性已经定义的值。总之，链接弧表示从xlink:from所代表的资源元素到xlink:to代表的资源元素之间的连接。由于xlink:from、xlink:to和xlink:label属性用于链接的遍历，因此这三个属性常被称为遍历属性（traversal attributes）。

如果xlink:from和xlink:to的值对资源元素是唯一的，即只有一个资源元素的xlink:label属性具有xlink:from或xlink:to指定的值，那么这个链接弧只包括一个连接，在有向图中表现为一条边。如果xlink:from和xlink:to的值对资源元素不唯一，即有多个资源元素的xlink:label属性具有xlink:from或xlink:to属性值，那么这个链接弧则表示多个连接，在有向图中表现为多条边。例如，下面例子中，扩展XML链接元素EXTLINK包含一个本地资源RESOURCE元素、三个远程资源LOCATOR元素和两个CONNECTION元素，它表示课程、教师和学生的关系。RESOURCE和LOCATOR元素的xlink:label属性依次定义为"DataStructure"、"teacher"和"student"，CONNECTION元素的xlink:from和xlink:to的值必须为上述三个值之一。

用有向图来表示上面的例子，可以看到第一个CONNECTION元素表示了一条有向边，而第二个CONNECTION元素表示了两条有向边，见下图。

xlink:from和xlink:to属性可以省略，这时表示该扩展XML链接元素包含的所有资源元素均参与到链接中。如果省略了xlink:from属性，那么该链接弧表示从所有资源元素到xlink:to代表的资源元素的连接；类似地，如果省略了xlink:to属性，则表示从xlink:from代表的资源元素到该扩展XML链接元素的所有资源元素的连接。如果xlink:from和xlink:to两个属性同时省去，则表示所有链接元素构成的全连接，其中包括了从每个链接元素到自身的链接。

链接弧元素的行为属性xlink:show和xlink:actuate的含义及取值与简单XML链接中的相应属性一样。语义属性xlink:arcrole和xlink:title则是用于描述相对于链接弧的起始资源而言，目标资源所具有的性质，我们可以将xlink:arcrole 理解为自然语言中的谓语，而链接弧起始资源是自然语言中的主语，目标资源是自然语言中的宾语，这样一个链接弧就可以对应于自然语言中的语句。对于同一个资源而言，它对不同的起始资源有不同的性质，因此一个资源在不同的链接弧中可以定义不同的语义属性。

最后需要注意的是：链接弧不能重复定义。也就是说，在同一个扩展XML链接中，不能定义多个链接弧元素，它们的xlink:from的值和xlink:to的取值都相同。

从前面三小节可以看出，无论是资源元素（本地资源和远程资源），还是链接弧元素，都提供了语义属性xlink:title，它使用可供人阅读的语言来描述相应的元素。但是，这种描述方式也存在它的局限性：首先，每个元素只能有一个xlink:title属性，在需要对一个资源进行多种描述的场合，它就无能为力。另外，xlink:title作为属性存在，不具有内部结构。对于一些希望用结构描述的资源，该属性也无法提供一个满意的办法。

为了解决上面提到的问题，XLink提供了一种称为title类型元素的特殊元素，它的xlink:type属性取值为"title"，title类型元素可以包含任意内容、属性，也可以包含子元素，因此可以实现资源多描述和内部结构。需要注意的是，title类型元素必须作为本地资源元素、远程资源元素或链接弧元素的直接子元素才具有链接意义。

下面是title类型元素的一个可能的DTD声明及实例。

至此，我们已经介绍完所有可能的链接元素类型。下面，我们根据这些类型对XLink属性的组合加以列表：