xml技术指南.docx

xml技术指南.docx

《xml技术指南.docx》由会员分享，可在线阅读，更多相关《xml技术指南.docx（41页珍藏版）》请在冰点文库上搜索。

xml技术指南

XML及其技术指南

       概要：

本文介绍了XML以及XML家族中的各项技术。

我们将讨论这其中的各项核心技术是如何组合成一个完整的整体以及一些支持XML技术的东西究竟是什么。

　　似乎这样的事情每天都在发生：

越来越多的开发者都相信XML（ExtensibleMarkupLanguage）将从根本上改变我们的软件业。

但如果你想从他们那里弄清楚这一切为什么或是何时将会发生时，你会发现他们给的解释中充斥着大堆有关XML的专有名词的缩写。

这些东西实际上并不能让你明白些什么，我相信你一定不会满意像他们这样的解释。

　　通常，人们在学习掌握XML时所遇到的主要障碍来自于XML惊人的发展速度。

如果你浏览一下W3C关于XML的网站（http:

//www.w4.org/xml/），你会发现有关XML的大量技术以及相关的出版物。

W3C将如此大量的信息聚集在一起，给开发者造成了不小的麻烦。

在对"XML所含盖的所用技术是如何整合在一起"这样关键性的问题还没用明确概念的情况下，想要学习XML是比较困难的。

　　本文向你介绍了XML和XML家族中的各项技术，使你不仅在更高层次上对XML的重要性有所了解，而且知道XML中的各项技术是如何组合在一起成为一项完整的技术。

读完本文，你会将会对困扰你的那些XML专用名词及其缩写用一个大致的了解，为你今后从更深层次学习XML打下基础。

　　那么，究竟什么是XML呢？

　　在很多介绍以前的XML的作者中，回答这个问题已经成为了一种风潮。

就像你已经熟知的一样，XML是ExtensibleMarkupLanguage的正式缩写。

他们可能认为XML的发音比EML读起来更性感，于是就将原先的字母E换成了字母X。

然而，当你跨过缩写从更深层次上来理解XML时，你会发现它不仅仅是一种标记语言，而是一系列的技术。

这一技术家族为我们开发具用更好的可扩展性和互操作性的软件提供了一种解决方案。

　　XML来自何处？

　　XML起源于SGML（StandardGeneralizedMarkupLanguage。

换句话说，你可以既使用XML也可以使用SGML来创建自己的描述性文档。

这两种语言都使用文本标识（Tags）来描述数据以供其他应用或是工具（例如一个SGML或是XML分析程序）使用。

有了XML，它们可以正确的读取信息并对数据进行一些有趣的操作。

XML是SGML的一个简化版本，它更适合于在Web上使用。

XML的语法

　　XML定义了用来描述你的数据的语法。

一下就是一句正确的XML语句：

1.　　＜hamburger name="CowBurger" lowfat="dream on"/＞  

　　和其他的标识语言有所不同，XML对大小写是敏感的。

所以，＜hamburger＞元素和＜Hamburger＞元素在XML中是不同的。

同时，XML不会忽略空格（其他的语言常常忽略空格）。

对每一个可能对文档结构造成混淆的字符，XML都会仔细的处理（就像＜and＞）。

　　如果一个XML文档只含有一个根元素，并且所有的子元素都被正确地放在父元素中，这样的XML具有良好的风格。

更具体地说，就是对每一个给定的子元素，它的begin和endtag都只存在于相同的父元素中。

下面就是一段风格良好的XML文档示例（hamburger.xml）。

1.＜?

xml version="1.0"?

＞  

2.＜hamburgers＞  

3.　＜hamburger lowfat="dream on"＞  

4.　　＜name＞CowBurger＜/name＞  

5.　　＜description＞Greasy and good.＜/description＞  

6.　　＜price＞2.99＜/price＞  

7.　＜/hamburger＞  

8.＜/hamburgers＞  

谁来定义Tags？

　　读了前面的部分后，你会发现你已基本上了解了XML的语法。

其实这里的内容并不是很多，XML确实是非常简单。

　　可能你已经注意到了，XML看起来很像HTML（HypertextMarkupLanguage）。

他们都用相同的语法来定义begin和endtag以及一些属性。

从本质上说，HTML使用的是一些预先设定好的元素和方法，只是XML的一个特例。

这些元素及其相关的方法决定了浏览器如何解释一个XML文档，进而提供给最终用户。

　　和HTML为创建用户界面提供了一种通用的方法一样，XML提供了一种描述并协同数据工作的通用方法。

XML允许开发者创建自己的XML词汇，用自定义的方式描述他们自己的数据结构。

假如一个开发者正在为一个快餐连锁店开发软件，那么，为了描述一些食品，一个"汉堡包"元素可能会十分的方便。

　　一旦开发者使用了XML来描述他们的数据，他们就可以很方便的在相同的或是不同的系统中对这些数据进行互操作。

当然，前提是那些系统都能理解XML。

譬如说，一位开发者可以使用来自另一个系统的数据，只要那些数据是用XML描述的。

如此一来，开发者在考虑软件的互操作性时就再也不必担心诸如平台、操作系统、语言、或是数据存储等各方面的不同了。

XML是实现系统之间互操作性的最简单工具。

　　XML的名字空间

　　由于XML对互操作性的支持，每个人都可以创建属于自己的XML词汇。

这样一来，如果不同的开发者用相同的元素来代表不同的实体的话，后果是不可想象的。

为了防止这种潜在的冲突，W3C在XML中引入了名字空间。

　　XML名字空间为你的XML文档元素提供了一个上下文。

它允许开发者按一定的语义来处理元素。

还以汉堡包举例说明，在某个系统中price元素可能代表的是消费者的购买价，而在另一个系统中，它可能代表了商店的进货价。

下面的例子演示了名字空间是怎样帮我们解决这样的问题的。

1.＜?

xml version="1.0"?

＞  

2.＜hamburgers  

3.　　xmlns:

purchase="http:

//fastfood.org/franchise/prices"  

4.　　xmlns:

sales="http:

//fastfood.org/customer/prices"  

5.＞  

6.　＜hamburger lowfat="dream on"＞  

7.　　＜name＞CowBurger＜/name＞  

8.　　＜description＞Greasy and good.＜/description＞  

9.　　＜purchase:

price＞0.99＜/price＞  

10.　　＜sales:

price＞2.99＜/price＞  

11.　＜/hamburger＞  

12.＜/hamburgers＞  

13.   

我怎样使用XML呢？

　　XML的语法并不难，但想要用好XML，让它帮我们做一些事还是有一定的挑战性的。

　　要用好XML，我们要能编程处理XML文件。

W3C定义了一种软件模型叫"XML处理器"。

它能够读XML文档并提供对其内容和结构的访问。

微软最主要的XML处理器叫做MicrosoftXML（MSXML）2.0。

MSXML2.0捆绑于IE5.0中，并且可以作为一个单独的可分发文件从微软MSDNXML的网站免费获得（

　　使用XML来作为描述数据的通用标准的一个主要优点在于，任何XML处理器所提供的功能都能让我们实现我们想到的目标。

开发者几乎不用（如果你曾这么干过）费力去写自己的XML处理器。

理论上说，开发者应该使用市场上最好的处理器以避免出现兼容的问题。

　　使用一个标准的XML处理器，你可以通过编程读各种XML文档（例如hamburger.xml），访问任何元素、元素内容或是元素属性。

如果你在一个基于Windows的系统中创建XML文档，你也可以很方便的将这个文档转到大型机系统中，用大型机的XML处理器来实现与同样数据的交互。

这才是XML的真正魅力所在。

作为一项技术，XML并不能解决你的软件的所有问题；但它已成为一种在你和他人的应用之间交换结构化数据的开放式有效机制。

　　XML的核心技术

　　直到现在，你已经完全可以创建使用属于你自己的XML文档了。

然而，XML真正的潜力却在于它所支持的多项技术。

你完全不必为此去使用本文以下所讨论的所有技术。

但它们的出现可以帮助你理解这些技术是怎样作为整个XML策略的一部分被组合在一起的。

　　确认技术

　　你已经知道了XML为描述结构良好的文档提供了一整套灵活的语法。

正因为它的这种灵活性，我们需要一些方法来确认某一种特殊类别的XML文档都有我们所预计一种格式。

例如，以下就是一个结构良好的XML文档：

1.＜?

xml version="1.0"?

＞  

2.＜hamburgers＞  

3.　＜hamburger lowfat="dream on"＞  

4.　　＜hamburger lowfat="maybe"＞  

5.　　　＜name＞CowBurger＜/name＞  

6.　　　＜description＞Greasy and good.＜/description＞  

7.　　　＜price＞2.99＜/price＞  

8.　　　＜price＞3.99＜/price＞  

9.　　＜/hamburger＞  

10.　＜/hamburger＞  

11.＜/hamburgers＞  

12.   

　　然而，这个文档有一些应用级的问题。

注意到了吗，文档中一个hamburger元素出现在了另一个hamburger元素的里面。

请别担心，对于这个例子来说这个XML结构没有任何的错误。

另外，请注意在里层的hamburger元素中有多个price元素。

哪一个price是正确的呢？

系统有可能会显示出这里有一个Bug。

在这种情况下，一个标准的确认XML文档的机制将是十分有用的。

　　schema

　　一个schema通常是一组为了描述一类给定的XML文档而预先定好的规则。

它定义了可以在指定XML文档中出现的各个元素以及和某个元素相关的若干属性。

它同时定义了关于XML文档的结构化信息，比如哪几个元素是其他元素的子元素，子元素出现的顺序和他们的数量。

它还可以定义一个元素是否为空，能否包含文本或者属性是否有默认值。

　　DTDs（DocumentTypeDefinitions）和XML数据都是怎样描述XML文档计划的具体例子。

　　文档类型定义（DocumentTypeDefinitions）

　　DTD语言是为了定义SGML文档的确认规则而专门开发的。

因为XML是SGML的一个子集，所以DTDs也可以用来定义XML的确定规则。

与XMLschema不同，一个XML处理器可以在运行时用DTD来确定一个XML的合法性。

　　DTD的语法有时可能会有一些晦涩难懂。

DTDs使用不同的语法元素，诸如惊叹号、圆括号、星号、尖括号等，来定义在一个XML文档中那些元素是必备的，哪些是可选的以及可以出现的元素数量等等。

DTDs同时还定义了元素之间的关系和属性于不同元素之间的关系。

　　下面就是前面列出的hamburger.xml的DTD（hamburger.dtd）：

1.＜!

ELEMENT hamburgers  （hamburger）*＞    

2.＜!

ELEMENT hamburger （name, description, price）＞    

3.＜!

ATTLIST　hamburger  lowfat CDATA #IMPLIED＞   

4.＜!

ELEMENT　name （#PCDATA）＞    

5.＜!

ELEMENT description  （#PCDATA）＞    

6.＜!

ELEMENT　price （#PCDATA）＞   

　　这篇文档指出，hamburgers元素可以包含多个hamburger元素。

同时，每一个hamburger元素必须包含一个lowfat属性和三个子元素，所有的类型都是#PCData（parsedcharacterdata）。

遵从这篇DTD的文档都必须加入下面一行代码：

1.　　＜!

DOCTYPE hamburgers SYSTEM "hamburger.dtd"＞  

　　这句声明告诉分析器不论DTD中的schema是什么都认为XML文档的内容是合法的

　　尽管MSXML2.0支持DTDs,但是你还是会发现使用它们是很费力的。

它非常复杂并且难于掌握与使用。

请注意，DTD语法并不是合法的XML。

正因为如此，XML的处理器除了XML语法，还要支持用来描述schema的DTD语法。

设想一下，假如我们用XML来描述schema，那么开发者，特别是XML工具的提供者，所承担的XML文档检验工作将会变得容易得多。

W3C正在考虑几种弥补DTDs不足的方案以提高现在的语法定义过程。

　　XML数据

　　XML-Data是一种XMLschema语言。

在微软的定义中，XML-Dataschema通常是指XMLschema，而不是DTDschema。

一个XML-Dataschema是一个具有良好结构的XML文档。

XML-Data语言基于XML-DataDTD，后者指明所期望的schema定义格式。

因为XML-Dataschema是简单的XML文档，任何用于XML文档的工具都可以用来定义XML-Dataschema。

　　以下的XML-Dataschema产生的schema和先前由hamburger.dtd所定义的schema是一样的：

1.＜?

xml version="1.0"?

＞  

2.＜Schema xmlns="schemas-microsoft-com:

xml-data"＞  

3.　＜ElementType name="name" /＞  

4.　＜ElementType name="description" /＞  

5.　＜ElementType name="price" /＞  

6.　　＜AttributeType name="lowfat" /＞  

7.　　　＜ElementType name="hamburger" /＞  

8.　　　＜element type="name" maxOccurs="1" /＞  

9.　　　＜element type="description" maxOccurs="1" /＞  

10.　　　＜element type="price" maxOccurs="1" /＞  

11.　　　＜attribute type="lowfat" maxOccurs="1" /＞  

12.　　＜/ElementType＞  

13.　＜ElementType name="hamburgers" model="closed"＞  

14.　　＜element type="hamburger" maxOccurs="*" /＞  

15.　＜/ElementType＞  

16.＜/Schema＞  

　　在XML-Dataschema中定义元素和属性时，分别用到的是＜ElementType＞和＜AttributeType＞元素。

它们提供了对元素和属性类型的定义。

定义一个元素或是属性时用＜element＞或＜attribute＞标签。

你可以通过定义minOccurs/maxOccurs来指定元素允许出现的数量。

schemaXML结构还定义了元素在XML文档中允许出现的位置（例如一个＜hamburgers＞元素可以包含若干＜hamburger＞元素，等等）。

　　微软通过MSXML2.0对XML-Data提供支持。

根据微软的XMLSDK文档，捆绑在IE5中的XMLschema的实现基本上依托于W3C于1998年1月发布的XML-DataNote。

它提供了对XML-Data子集的支持，这虽然和XML的语法稍有不同，正好直接和DCD中阐明的功能相吻合。

　　处理器（API）技术

　　我们在前面已经提过了，为了有效的使用XML，你必须通过编程来访问数据。

我们将一个能访问XML文档同时又能提供对其内容和数据结构进行访问的软件模块称为一个XML处理器或是一个XMLAPI。

　　虽然开发者完全有自由去开发或使用他们自己的XMLAPI，但从他们的利益出发，我还是建议他们使用行业标准的API。

因为只有接受了行业标准的API，开发者写出的代码可以无需修改便能在其他的环境中顺利执行。

　　目前有两种主要的API已经得到了广大开发者的广泛使用，即将成为未来的行业标准。

它们分别是：

DOM（DocumentObjectModel）和SAX（SimpleAPIforXML）。

　　DOM文档对象模型

　　文档对象模型是一种通过编程方式对XML文档中数据及结构进行访问的标准。

W3C已经同意将其列为未来行业标准第一等级规范的推荐对象。

　　DOM是基于XML文档在内存中的树状结构。

当一个XML文件被装入到处理器中时，内存中建立起一棵相应的树（见图1）。

DOM还定义了用来遍历一棵XML树和管理各个元素、值和属性的编程接口（包括方法和属性的名字）。

Figure1.XMLin-memoryrepresentation

　　MSXML2.0完全支持DOM并提供了一个易用的对象模型与内存中树进行交互。

下面是一个简单的VB例子，它演示了如何用MSXML来遍历一颗树的所有子元素。

1.Set xmlDoc = CreateObject（"MSXML.DOMDocument"）  

2.bSuccess = xmlDoc.load（"hamburger.xml"）  

3.If bSuccess Then  

4.　For Each node in xmlDoc.documentElement.childNodes  

5.　　val = node.text  

6.　Next  

7.End If  

　　SAX

　　DOM标准的一个主要不足在于将整个XML文档装入内存所引起的巨大开销。

当文件的数据量非常大时，这会给我们带来一些问题。

当你在内部网或是因特网上传输如此巨大的XML文件时，你可能等不及所有的文件传输结束就开始处理数据。

很多XML的开发者已经意识到这一点，于是他们一起努力（从XML-DEV邮件列表开始）开始创立另一种新的标准。

这就是SAX。

虽然SAX还处于发展的初期，但因为它出色的性能，它正快速的得到大家的欢迎。

　　SAX是一种非常简单的XMLAPI（正如它的名字那样，SimpleAPIforXML），它允许开发者使用事件驱动的XML解析。

与DOM不同，SAX并不要求将整个XML文件一起装入内存。

它的想法十分的简单，一旦XML处理器完成对XML元素的操作，它就立刻调用一个你自定义一个事件处理器及时的处理这个元素和相关数据。

这样做虽然能极大的提高效率，但也会造成一定的问题。

比如说，开发者将不得不在灵活性上受到限制。

如果你想了解更为详细的资料，请访问

　　转换技术

　一旦你开始使用标准的DOMAPI来实现于XML数据的交互，你便会发现，无论是从一个大型的文档中取得一个特定的数据，还是将一个XＭＬ文档的某一部分转换为另一种格式的数据（例如ＨＴＭＬ），都是十分单调乏味的。

　　举个例子说，假如你想找到所有的lowfathamburgerprice元素。

为了用标准的DOMAPI来完成这一切，你必须通过手工地书写代码遍历整颗树来找寻符合条件的元素（在本例中，条件是指在hanburger元素中lowfat=yes的price元素）。

再看另一个例子，假设你想将所用的hamburger元素和相关的数据转换为简单的HTML表格以供用户交互使用。

使用标准的DOMAPI，你得手工遍历整棵树来获得HTML表格中所需的数据。

　　我为了标准化及简化人们完成这些任务所需做的工作，W3C推荐使用XSL（ExtensibleStylesheetLanguage）和一种叫做XSLPatterns的简单查询语言。

　　XSLPatterns

　　一个模式就是一个字符串，通过它来选取XML树中的节点。

这样的选取取决于模式所关连的当前节点。

元素的名字是最简单的模式，这个模式选取了当前节点所有具有该名字的子节点。

例如，hamburger模式选取了当前节点的所有hamburger子节点。

　　模式的语法非常完备。

它允许你标识某个指定元素在文档中所处的上下文（例如，price元素在hamburger元素之中），同时它还提供了强大的筛选句法，使得我们可以标识出符合给定条件的节点（例如，lowfat=yes）。

为了找出一个hamburgers元素中的所有lowfathamburgerprice元素，你可以使用以下的模式字符串：

　　/hamburgers/hamburger[@lowfat="yes"]/price 

　　当某个模式被应用于给定的节点时，它仅返回符合指定模式的节点列表。

这大大简化了开发者的操作，不再需要遍历整棵树。

　　MSXML2.0对模式语法的支持和ExtensibleStylesheetLanguage（December18thWorkingDraft）中2.6节的定义是相同的。

MSXML2.0中的IXMLDOMNode接口提供了两个方法，SelectNodes和SelectSingleNode。

这两个方法都以一个模式串为参数。

例如，下面的一行代码将返回满足条件的所有price节点。

1.Set nodeList = rootNode.selectNodes（"hamburger[@lowfat="yes"]/price"）  

　　XSL

　　XSL模式可以帮助我们标识一篇给定XML文档中的某些节点，但对这些节点的操作最终还是有赖于开发者来完成。

XSL可以帮助我们简化完成通常XML任务的过程：

将XML节点从一种格式转化到另一种格式。

这种对格式转化的需求起源于Web开发者需要将他们的XML数据转化为HTML数据以供用户浏览。

　　实际上，XSL所能做得远比以上描述多得多。

XSL能够有效的定义从一种XML格式到另一种XML格式之间的转换，这极大的增强了互操作性。

假如某个人向你的系统发送了一篇XML文档，而你的系统不认识它所采用的XML词汇，你只要进行一次简单的XSL转换就可以得到自己熟悉的词汇。

正是由于XML这种简单的特点，开发者才不用为了描述某种类型的数据而采用通用的词汇。

　　一个XSL文件中包含了一系列定义转换规则的声明模板。

每一个模板都明确定义了怎样将源文档中的指定节点转换为输出文档中的节点（或其它类型的数据）的方法。

你可以使用XSL模式来决定一个模板应用于一篇文档中的那些部分。

　　作为一个示例，下面转换hamburgerXML文件：

1.＜?

xml version="1.0"?

＞  

2.＜hamburgers＞  

3.　＜hamburger lowfat="dream on"＞  

4.　　＜name＞CowBurger＜/name＞  

5.　　＜description＞Greasy and good.＜