XML有什么用，用来做什么的？(0分)

XML有什么用，用来做什么的？

1.1 什么是XML
1.1.1 描述性语言介绍
对XML感兴趣的你是否熟悉当前在网络上大行其道的超文本描述语言HTML
（HyperText Markup Language）呢？是否对HTML所带代表的"描述性"这
一概念也有所了解呢？要知道，XML和HTML同属一个大家族--描述语言家族，
因此，为了让大家更好地理解XML，我们就首先从HTML讲起，介绍一下描述性语言的概念。
顾名思义，HTML的精髓在于"描述"（Markup），通俗地讲，它就是一种用来给文本添加
标记的语言。那么，"描述"的精确定义究竟是什么呢？
"描述"的一个精确定义是：就数据本身的信息对数据进行编码的方法。
是不是这个定义有点过于抽象了？没关系，其"描述"的概念在现实生活中比比皆是，
我们只须看看下面这个例子就明白了。
想必大家都有这样的经历--在上学时，曾经用黄色荧光笔把课本上的某些句子加亮，
或者干脆在这些句子下面划线--相信即便你自己没有这样做过，
你也见过身边的同学这样做。而之所以要将这些句子用荧光笔加亮，
是因为你觉得它们很重要。考试前，这些内容需要复习一下，只要跟着这些加亮标记，
你就可以迅速地把它们浏览一遍。事实上，不光是你，世界上成千上万的人都在为同样
的理由做同样的事情。
其实，正是通过将这些内容加亮，你已经有效地将它"描述"了。把它们用黄色荧光加亮。
表示这些课文很重要，关于这些课文的信息--即这些课文很重要这一事实--就这样被编码了。

不仅如此，由于几乎所有人都遵循着和你一样的描述标准（难道你见过专门挑那些不
重要的课文加亮的人吗？），当你拿起一本别人的课本随便翻翻时，你只要看看那些作
了加亮标记的段落，就可以对这本书的精华略知一二了。
从这个例子中我们可以得到两点启示。当我们需要通过标记将有用的信息告知一组用户时：

首先，我们必须有一个标准，用它来描述什么是有效的标记。在上面例子中，标记被定义为在文字上的黄色荧光墨水印迹。而在HTML中，标记就是所谓的"标签"（tag）。
其次，我们还要有一个标准描述每个标记的具体含义。上面例子中的黄色荧光加亮标记意味着被加亮的句子很重要。而在HTML中，每一个标签都表明了一种显示的格式。
同样，"描述"的应用在计算机世界中也甚为广泛。文字编辑器借助特殊标识符号来描述格式与外观，通信程序依靠标志位来理解线路上所传输的信息的语意，数据库通过标识符号来将数据字段与一定的含义相连，并表明字段之间的关系，多媒体应用中标识符号来标示什么是图象和声音的源数据。
当这些数据被传送给计算机或应用程序时，它必须自身携带一些必要的信息，以表明这些数据的含义，以及接收者应该如何处理这些数据。
可以想象，到了考试期间，如果你的课本上没有任何重点标记，你只能对着它望洋兴叹。同样，如果数据中不带有任何背景信息，应用程序也只能对它望洋兴叹！HTML就是众多著名的计算机描述系统中的一个。它描述了一系列标签，每个标签表明了一定的显示格式。被标识后的文件（即同时包含了纯文本和关于文本显示格式的标签的文件）由一个HTML处理工具，譬如一个浏览器，进行读取，然后再根据上述标记规则来加以显示。
最后，让我们通过一个例子来看看HTML中的标识是如何大显神通的。在HTML中，标签〈B〉的含义是要求HTML浏览器将一段文本加粗表示，而标签〈CENTER〉的含义是告诉浏览器将这段文本在一行的中间显示。所以，在浏览器中，〈CENTER〉〈B〉BOLD〈/B〉〈/CENTER〉是如下显示的：
BOLD
同样，下面这一段HTML代码显示了一个客户联系信息列表：
<UL>
<LI>张三</LI>
<UL>
<LI>用户ID: 001</LI>
<LI>公司: A公司</LI>
<LI>EMAIL: zhangG@aaa.com</LI>
<LI>电话: (010)67394409</LI>
<LI>地址: 五道口街1234号</LI>
<LI>城市: 北京市</LI>
<LI>省份: 北京</LI>
<LI>ZIP: 100001</LI>
</UL>
<LI>李四</LI>
<UL>
<LI>ID: 002</LI>
<LI>公司: B公司</LI>
<LI>EMAIL: li@bbb.org</LI>
<LI>电话: (021)63211500</LI>
<LI>地址: 南京路9876号</LI>
<LI>城市: 上海市</LI>
<LI>省份: 上海</LI>
<LI>ZIP: 200002</LI>
</UL>
</UL>
这段HTML数据在浏览器中的显示效果如下：
· 张三
o 用户ID: 001
o 公司: A公司
o EMAIL: zhang@aaa.com
o 电话: (010)62345678
o 地址: 五街1234号
o 城市: 北京市
o 省份: 北京
o ZIP: 100001
· 李四
o ID: 002
o 公司: B公司
o EMAIL: li@bbb.org
o 电话: (021)87654321
o 地址: 南京路9876号
o 城市: 上海市
o 省份: 上海
o ZIP: 200002
当我们对"描述"的含义有了一个明确的理解后，我们对XML的精髓就已经掌握了一半。那么，描述性在HTML中的形式和作用与在XML中的形式和作用又有什么不同呢？下一节我们来讨论这个问题。
1.1.2 什么是XML语言
正象HTML一样，可扩展描述语言XML（eXtensible Markup Language）也是一种描述性语言。它同样依赖于描述一定规则的标签和能够读懂这些标签的应用处理工具来发挥它的强大功能。这一点，从XML的命名上也可窥见一斑。
"关于此规范的正确题目，亦即XML的正确全名，应该是Extensible Markup Language， eXtensible Markup Language只不过是一个拼写错误罢了。但是，现在简写XML不仅正确，而且正如它在本规范的标题中一样，是Extensible Markup Language的官方名称。
这个名称和简写是由James Clark最先提出的，其它可供选择的名称还包括小型标准描述语言MGML (Minimal Generalized Markup Language), 标准描述语言的小型结构MAGMA (Minimal Architecture For Generalized Markup Applications), 以及互联网描述结构语言SLIM (Structured Language for Internet Markup)。
--Extensible Markup Language (XML) 1.0 Specs, The Annotated Version. "
从对XML的最初命名可以看出，XML的核心归根结底还是描述语言。不过，XML这个描述语言可比HTML的功能要强大的多了。
"人"如其名，XML的强大功能来自于"X"。也就是说，XML不但是描述语言，而且是可扩展的（eXtensible）描述语言。XML并非象HTML那样，提供了一组事先已经定义好了的标签，而是提供了一个标准，利用这个标准，你可以根据实际需要定义自己的新的描述语言，并为你的这个描述语言规定它特有的一套标签。准确的说，XML是一种源描述语言，它允许你根据它所提供的规则，制定各种各样的描述语言。这也正是XML语言制定之初的目标所在。
XML的制定目标为：
1.XML应该可以在互联网上直接使用（*就像HTML那样好用）。
2.XML应该支持各种不同的应用方式（*不但包括浏览，还包括对内容的分析）。
3.XML应该与SGML兼容（子承父业嘛，后面我们会讲到，SGML是XML的直接先驱）。
4.处理XML文件的应用程序应该容易编写（计算机系的研究生花上两周的工夫就该差不多了）。
5.XML中的可选特性的数量应该减到最小，最好减至没有（可选特性经常造成混淆）。
6.XML文件应该具有良好的可读性，并且比较清晰（别像HTML那样，如果不借助浏览器，要想读它简直就是对你意志力和耐心的考验）。
7.用XML设计新的描述语言应该方便快捷（你不必再去经历标准制定的繁琐程序了）。
8.XML设计的描述语言应该正式、简洁（不然怎么易写易读？）。
9.XML文件应该容易编制（想想要用"记事本"写个HTML是一件多么可怕的工作）。
10.XML标记的简洁性并不重要（你不必再去费尽心机减少标记）。
--Extensible Markup Language (XML) 1.0 Specs, The Annotated Version."
让我们来考虑一个非常简单的例子。如果我们需要定义一个新的描述语言，叫做FCLML（F_company s Client List Markup Language）--F公司的客户列表描述语言。这个语言应该定义一些标签来代表可联系的客户和有关他们的信息。这组标签很简单，它们的优点是代表了一定的语意。让我们回想一下上一节中这些信息在HTML中是如何用标签〈UL〉和〈LI〉表示的。与之相比，下面这一段代码，显然更加清晰易读：
<联系人列表>
<联系人>
<姓名>张三</姓名>
<ID>001</ID>
<公司>A公司</公司>
<EMAIL>zhang@aaa.com</EMAIL>
<电话>(010)62345678</电话>
<地址>
<街道>五街1234号</街道>
<城市>北京市</城市>
<省份>北京</省份>
<ZIP>100001</ZIP>
</地址>
</联系人>
<联系人>
<姓名>李四</姓名>
<ID>002</ID>
<公司>B公司</公司>
<EMAIL>li@bbb.org</EMAIL>
<电话>(021)87654321</电话>
<地址>
<街道>南京路9876号</街道>
<城市>上海</城市>
<省份>上海</省份>
<ZIP>200002</ZIP>
</地址>
</联系人>
</联系人列表>
这一段代码是一个非常简单的XML文件。看上去它和HTML非常相象，但细心的人会发现这里的标签代表的不再是显示格式，而是对于客户信息数据的语意解释。
事实上，用XML定义的描述语言可以根据标记描述的侧重点不同分为两大类。一类偏重于语意描述，正如上面这个例子。还有一类偏重于显示方式的描述，像现在已经出炉的XHTML、SVG、SMIL，后面我们还会详细讲解。值得一提的是，这里对于显示方式的描述不仅限于对文本的描述，还可以包括矢量图形、图像、声音。比如，一个形如〈EMPHASIZE〉的标签在描述文本时可能是要求将文本加粗，而在描述声音时则要求将音量加大。
不过，正如我们上节所述，仅仅将数据加以标识还不够。为了让别人读懂这些数据，描述语言中的标准还需包括：
1.标识的语法
2.每个标识的含义
换句话说，如果想让计算机应用程序读懂并能处理这段数据，它还必须知道什么是一个有效的标识（如标签），如何处理一个有效的描述。具体地说，Netscape浏览器如何知道怎样显示上面的这段XML文件？标签〈电话〉是什么含义？它究竟是不是一个合法的标签？它又应该以什么方式表现？因此，我们的描述语言必须能够告诉应用程序它所采用的标识的语法，以便于应用程序对其处理。
在XML中，标识的语法是通过文件类型定义DTD（Document Type Definition）来描述的。也就是说，我们通过DTD来描述什么是有效的标签，从而进一步定义描述语言的结构。在用XML定义的描述语言中，DTD与数据文件是分离的部分。第三章我们将详细讨论DTD的定义方法。这里我们先给出关于上例的DTD描述，让大家先睹为快：
fclml.dtd:
<?xml version="1.0" encoding="GB2312"?>
<!ELEMENT 联系人列表 (联系人)*>
<!ELEMENT 联系人 (姓名,ID,公司,EMAIL,电话,地址)>
<!ELEMENT 地址 (街道,城市,省份)>
<!ELEMENT 姓名 (#PCDATA)>
<!ELEMENT ID (#PCDATA)>
<!ELEMENT 公司 (#PCDATA)>
<!ELEMENT EMAIL (#PCDATA)>
<!ELEMENT 电话 (#PCDATA)>
<!ELEMENT 街道 (#PCDATA)>
<!ELEMENT 城市 (#PCDATA)>
<!ELEMENT 省份 (#PCDATA)>
同样，除了定义描述代码的语法外，我们还需定义描述代码的具体含义。为了明确各个标签的意义，XML使用与之相连的样式单（style sheet），由它来向应用程序，比如浏览器，提供如何处理显示的指示说明。一个样式单的具体格式我们在第四章再具体描述，现在我们只需知道，样式单所作的规定可能是这样的：
每当看到一个〈联系人〉标签，用一个〈UL〉标签显示它。同样，〈/联系人〉转换为一个〈/UL〉标签。
所有的〈姓名〉标签被转换为〈LI〉标签加以显示。同样，〈/姓名〉转换??LI〉标签。
所有的〈EMAIL〉标签被转换为〈LI〉标签加以显示。同样，〈/EMAIL〉转换为〈/LI〉标签。
等等...
在这个样式单的例子中，我们使用HTML的标签功能来定义我们的FCLML的显示格式。但如果XML文件不是由浏览器，而是由其它应用程序来进行处理，我们可能采用其它相应的标签。于是乎，我们的应用处理程序要综合DTD，样式单以及FCLML文件数据三方面要素，根据这些数据和规定来显示它。
看到这里，你可能会长叹一声：这不是越来越复杂了吗？原先只要一个HTML就能把数据和显示方式都包括进去，现在我们需要FCLML文件，DTD，样式单--总共三个文件！这还不算，我们需要一个处理工具把DTD、样式单、FCLML三者合一。别忘了，浏览器只是用来处理一种特定的描述语言（比如HTML）的，而不是用来处理所有描述语言的。这说明我们不但要把三个文件合一，还要制作或购买一个新的应用处理程序。太恐怖了！
"一个被称作XML处理器的软件模型应该能够读入一个XML文件，并解释其内容和结构。XML处理器是基于另一个称作应用的模型来进行这种处理的。
--Extensible Markup Language (XML) 1.0 Specs, The Annotated Version
的确，对于初学者而言，在使用XML时确实要克服一些障碍，不过在下面一节中，你将看到，这是非常值得的。
1.2 为什么我们需要XML
1.2.1 HTML的现状
可能大部分网页制作者对HTML仍然情有独钟，一听说要有一个新的语言来代替它，本能地先想为老朋友辩护两句。HTML怎么啦？它不是挺好的吗？
不错，说起当今世界互联网的蓬勃发展，HTML的确立下了赫赫战功。可是，HTML自身的特点使它蕴藏了许多危机，随着它不断的发展，这些危机不但没有减弱，反而越来越突出，甚至已然成为HTML继续发展应用的障碍。当然作为一门被广泛应用多年的成熟的描述语言,HTML本身仍然具有不可磨灭的优点，所以本文依然以这两种语言作为主要介绍对象。
HTML制定之初的本意在于根据信息的含义来为它们添加标识符号，而没有具体规定它们应该如何在浏览器中显示。回忆一下，在HTML的早期版本中，<title>代表题目，<h1>代表第一层的大标题，<h2>代表第二层的大标题，<em>、<strong>代表强调的文本，<address>代表作者的联系信息。至于这些题目、各层大标题应该如何显示，应该由浏览器决定，因为HTML标准的制定者相信，比起网页的制作人员，浏览器更了解用户的偏好和使用的浏览环境。显然网页的制作者事先并不知道哪些用户决定不显示图片，又有哪些用户喜欢大一些的字体，只有浏览器才能保证为这些特殊用户提供良好的支持。
不幸的是，浏览器的开发者同样也不大了解这些特殊用户的偏好，不仅如此，他们也不大想了解这些信息。相反，他们引入了自己定义的一些标签和属性，用这些新的标签来专门描述显示格式，比如标?lt;font>、<center>、<bgcolor>等等。浏览器厂商还开发了自己的网页制作软件，如Netscape开发的Netscape Composer，微软开发的Frontpage等等。这些所见即所得的网页制作工具自动生成HTML文件，而这些HTML文件更是忽略了标签的语意信息，而几乎完全将它们作为格式表现的工具。比如说，现在关于表格的标签，如<table>、<tr>、<td>等，不仅可以代表表格中不同行、列的信息，还可能专门用于网页布局。这样一来，HTML越来越侧重于信息的表示，标签中原本就很微弱的信息描述的含义也被削弱了。最后，HTML终于演变为专门用于Netscape和Microsoft IE两大浏览器的页面显示语言。
可能你觉得虽然某些有特殊癖好用户的要求得不到满足，但毕竟对大多数人而言，浏览页面最基本的问题--显示问题，还是解决了。而且，有了这些专门的显示标签，这个问题还是解决得不错嘛！其实不然。浏览器生产厂家在激烈的市场竞争中，为了显示自己的独特性，IE和Netscape都给HTML加入了一些特殊的标记，以便为自己的浏览器增加一些特殊的显示效果。日益增多的标签不但使HTML越来越庞大，浏览器的开发越来越复杂，还降低了不同浏览器之间的兼容性。比如说你的网页是针对IE5浏览器、800*600屏幕分辨率来制作的，那么在640*480的屏幕上观看的效果就会大打折扣，而如果放到Netscape浏览器中，显示效果与最初的设计构想甚至会大相径庭。
不仅如此，尽管HTML的标签越来越多，其显示力却还远远不够。如果你希望非常精确地表现一些你自己的数据，可能你需要一些现在HTML中尚不存在的标签。比方说，你是一个化学家，你可能需要表现化学分子式中的一些特别的符号。又比方说，你是一个飞机设计师，你希望能够表现飞机的动力引擎。可对于这些，HTML都望尘莫及。要想满足各行各业对显示的不同要求，显然需要大量的标签，这无疑给当今日益臃肿的HTML雪上加霜。
问题还不止这些，现在HTML内部结构的条理性越来越差。你写的HTML文件，甚至是那些专门的所见即所得工具自动生成的HTML文件，可能在语法上会错误百出，不过没关系，浏览器照样能读它。HTML中的文件可以不具有嵌套关系，比如<h1><h2></h1></h2>，也可以不配对出现，只有<h1>而没有</h1>，更不会要求你在使用标签<h2></h2>的外面一定要保证有<h1></h1>，（在语意上难道不该先有一级标题，再有二级标题吗？）。乍一看，这仿佛对网页制作者而言是个福音，可对浏览器的开发者就是件头痛的事了，他们不得不把大量的精力耗费在文法错误的包容上，相应的，浏览器的程序也要加大，甚至牺牲浏览时的时间效率和空间效率。
另外，还更有一批对HTML无可奈何的人，那就是搜索引擎的开发者。因为从HTML的标签本身，他们几乎得不到任何有用的信息。如果你要到网上去找出世界上所有关于XML的书籍的价钱，搜索引擎要被你忙坏了。它要分辨网络上哪些"XML"字段对应的是书名，又要知道这些书名所对应的价钱。可能你会说，在我们图书馆的网页中，这不是已经办到了吗？问题就在这里，图书馆是根据内部的数据库来进行搜寻的，数据库中的各个字段都有着明确的含义。但搜索引擎在网上是根据HTML文件来进行搜索的，那些原本条理清晰、层次分明的数据库的内容在HTML文件中早就被各种各样的标签搞得混乱不堪，而搜索引擎则不得不在这些混乱的内容中大海捞针！
HTML的这许多弊病，使它进入了一种"山重水复疑无路"的境地。那么，XML又是怎样带来了"柳暗花明又一村"呢？
1.2.2 XML的第一优势-自由与开放
XML仿佛充当着自由宣言的角色，它打破了标记定义的垄断，将网上世界变为一个更加自由民主的世界。不管你是否相信，我一直认为，互联网时代应该是以自由民主和开放为时代主题的。
不知你是否清楚在没有XML的时候，要想定义一个描述语言并推广利用它是何等困难。一方面，如果你制定了一个新的语言而期望它能生效，你需要把这个标准提交给相关的组织，例如W3C，等待它接受并正式公布这个标准，经过几轮的评定、修改、再评定、再修改，等到你的描述语言终于熬到成为一个正式推荐标准，可能几年的时间都已匆匆而过了。另一方面，为了让你的这套标记得到广泛应用，你必须为它配备浏览工具。这样，你就不得不去游说各个浏览器厂商接收并支持你的标记，或者索性自己开发一个新的浏览器去与现有的浏览器竞争，无论哪个办法，都令人望而却步！
现在有了XML，你终于可以自由地制定你自己的描述语言，而不必再念念不忘微软、Netscape、W3C的首肯了(当然，实际情况恐怕很难如此)。
当然，别以为XML的主要目的真的仅仅是为了提供一种祥和的气氛，体现新时代的自由平等的主旋律，它在网络应用中有着确确实实的作用。大家都知道，各个不同的行业可能会有一些独特的要求。比如说，化学家需要化学公式中的一些特殊符号，建筑设计图纸中需要某些特制的标记，音乐家需要音符，这些都需要单独的标记。但是，其它网页设计者则用不着这些记号，也不需要这些标记。XML好就好在它允许各个组织、个人建立适合他们自己需要的标记库，并且，这个标记库可以迅速地投入使用。
不仅如此，随着当今世界越来越多元化，要想定义一套适合各行各业、能够普遍应用的标记既困难，也没有必要。XML允许各个不同的行业根据自己独特的需要制定自己的一套标记，但它并不强迫所有浏览器都能处理这些成千上万的千奇百怪的标记，同样也不要求描述语言的制定者制定出一个非常详尽非常全面的语言从而适合各个行业各个领域的应用。比起那些追求大而全的描述语言的做法，这种具体问题具体分析的方法实际上更有助于描述语言的发展。
实际上，现在许多行业、机构都利用XML定义了自己的描述语言。比较早而且比较典型的是下面两个实例：
(1)化学描述语言CML (Chemistry Markup Language)
by Peter Murray-Rust
Peter Murray-Rust的化学标记语言（Chemical Markup Language，简写为CML）可能是第一个XML应用。CML原来是要发展成SGML应用的，但随着XML标准的发展，逐步演化成了XML。在CML的最简单的形式下，CML是"HTML加分子"，但是它的用处却超出了Web的范围。
分子文档常常包括成千上万个不同的详细的对象。例如，单个中等大小的有机分子可能含有几百个原子，每个原子有几个化学键。CML寻求以一种直接方式组织这种复杂的化学对象，以便能够让计算机理解，并显示和能够加以检索。CML可以用于分子结构和序列、光谱分析、结晶学、出版、化学数据库和其他方面。它的词汇表包括分子、原子、化学键、晶体、分子式、序列、对称、反应和其他化学术语。
例如，清单2-1是描述水（H2O）的基本CML文档：
清单2-1：水分子H2O
<?xml version="1.0"?>
<CML>
<MOL TITLE="Water">
<ATOMS>
<ARRAY BUILTIN="ELSYM">H O H</ARRAY>
</ATOMS>
<BONDS>
<ARRAY BUILTIN="ATID1">1 2</ARRAY>
<ARRAY BUILTIN="ATID2">2 3</ARRAY>
<ARRAY BUILTIN="O DE ">1 1</ARRAY>
</BONDS>
</MOL>
</CML>
CML提供的对传统的管理化学数据的方法的最大改善在于数据的检索。CML还使得复杂的分子数据可在Web上发送。由于XML的底层是与平台无关的，所以可以避免由于使用不同的平台而引起的二进制格式不兼容的问题，这种问题在使用传统的化学软件和文档（如Protein Data Bank (PDB)格式或者MDL Molfiles）时常常可以遇到。
Murray-Rust还创建了第一个通用目的的XML浏览器JUMBO。图2-1是JUMBO正在显示的一个CML文件。Jumbo将每个XML元素赋给能够显示这些元素的Java类。为了使Jumbo支持新的元素，只要编写用于该元素的Java类即可。Jumbo是与显示基本的一套CML元素（其中包括分子、原子和化学键）的类一起发布的。Jumbo可从http://www.xml-cml.org/ 站点处得到。
(2)数学描述语言MathML (Mathematical Markup Language) 1.0 Specification
W3C Recommendation 07-April-1998
传说CERN的Tim Berners-Lee发明了World Wide Web和HTML，这样一来，高能物理学家们就可以交换论文和印前出版物了。从我个人角度来说，我从不相信这个传说。我是学计算机的，但是根据我多年的学习经验,数学,物理学,这几个学科的论文有一点是共同的，就是论文中充满了大量的方程。直到目前为止，Web已经出现了有九年时间了，还没有找到一种在Web页面上包括方程的好办法。
现在有几种办法如Java小程序，可以分析自定义的句法，还有一种转换程序，可将用LaTeX软件编辑的方程转化为GIF图像，另一种是自定义的浏览器，可以读取TeX文件，但所有这些办法都不能产生高质量的结果，而且这些都不能满足Web作者（即使是科学领域的作者）的需求。最终，只有XML才能开始改变这种状况。

显示CML文件的JUMBO浏览器
数学标记语言（Mathematical Markup Language，MathML）是一种用于数学方程的XML应用。MathML具有足够的能力来处理大多数形式的数学问题从初中的算术到微积分和微分方程。它也可以处理许多更为高级的课题，但还存在一些空白，如在某些数学的分支中使用的更为高级也更为晦涩的记号。虽然对于MathML来说，在纯数学和理论物理的高端还有局限性，但是却足以处理几乎所有的教育、科学、工程、商业、经济和统计学上的要求。而且将来MathML必然要加以扩展，因而可以认为，即使是最纯粹的数学和纯理论的理论物理都能够在Web上出版和进行研究工作。MathML完成了Web向着科学研究和通信方面的有用工具方向的发展 （尽管说它也适用于作为新媒体来制作广告小册子有点离题太远）。
Netscape Navigator和Internet Explorer还不支持MathML。但是许多数学家都抱着热烈的希望，希望这些浏览器在不久的将来能够对此加以支持。W3C已经将某些对MathML的支持集成到他们的浏览器测试平台Amaya中了。下图是Amaya显示的用MathML编写的Maxwell方程的协变形式。

Amaya浏览器显示的用MathML编写的协变形式的Maxwell方程
MathML中的麦克斯韦（Maxwell）方程
<?xml version="1.0"?>
<html xmlns="http://www.w3.org/TR/REC-html40"
xmlns:m="http://www.w3.org/T / EC-MathML/"
>
<head>
<title>Fiat Lux</title>
<meta name="GENERATOR" content="amaya V1.3b" />
</head>
<body>
<P>
And God said,
</P>
<math>
<m:mrow>
<m:msub>
<m:mi>&amp;delta;</m:mi>
<m:mi>&amp;alpha;</m:mi>
</m:msub>
<m:msup>
<m:mi>F</m:mi>
<m:mi>&amp;alpha;&amp;beta;</m:mi>
</m:msup>
<m:mi></m:mi>
<m:mo>=</m:mo>
<m:mi></m:mi>
<m:mfrac>
<m:mrow>
<m:m >4</m:m >
<m:mi>&amp;pi;</m:mi>
</m:mrow>
<m:mi>c</m:mi>
</m:mfrac>
<m:mi></m:mi>
<m:msup>
<m:mi>J</m:mi>
<m:mrow>
<m:mi>&amp;beta;</m:mi>
<m:mo></m:mo>
</m:mrow>
</m:msup>
</m:mrow>
</math>
<P>
and there was light
</P>
</body>
</html>
上面的程序是混合使用HTML/XML的页面的例子。其中文本（"Fiat Lux"、"Maxwell’s Equations"、"And God said"、"and there was light"）的标题和段落是用经典的HTML编写的。实际的方程是用MathML编写的，这是一个XML应用。
一般来说，这种混合页面需要浏览器的特殊支持，这里也正是这种情况，否则就得有插件、ActiveX控件或是JavaScript程序来分析和显示内嵌的XML数据。当然最终用户需要像Mozilla 5.0或是Internet Explorer 5.0这样的浏览器，这两种浏览器可以分析和显示纯XML文件，而不需要HTML作为中介。
频道定义格式CDF是XML的又一大应用, Microsoft的频道定义格式（Channel Definition Format，简写为CDF）是用于定义频道的XML应用。Web站点使用频道向预订站点的用户传送信息，一改过去那种坐等用户前来浏览并获取信息的状况。这也叫做Web广播或是"推"。CDF首先是在Internet Explorer 4.0中引入的。
CDF文档是一个XML文件，与被推的站点的HTML文件分别存放，但是却链接到此HTML文件上。CDF文档中的频道定义决定了要发送哪个页面。页面可以通过发送通知向预订者加以推送，但也可以发送整个站点，或是由阅读者在方便的时候自己来"拉"信息。
用户可向自己的站点添加CDF，而不用改变现存的所有内容。只要在页面上添加与CDF文件的一个不可见的链接即可。当浏览者访问这个页面时，浏览器显示一个对话框，询问浏览者是否要预订频道。如果浏览者选择了预订，则浏览器就下载描述频道的CDF文档。然后浏览器将CDF文档用指定的参数与用户自己的优选项结合起来，以便决定什么时候检查服务器上的新内容。这实际上不是真正的"推"，因为客户必须初始化连接，但是这确实是在没有浏览请求的情况下发生的。下图是IDG的Active Channel（活动频道）显示在Internet Explorer 4.0中的情况。

在Internet Explorer 4.0中显示的IDG的Active Channel(活动频道)
可扩展性表单描述语言: 今天我到我家附近的书店买回了一本石康的小说，名为<晃晃悠悠>。因为没有带钱(这里只是举个例子),于是因为和书店老板比较熟悉,就写了一个欠条,如果我在一个礼拜内不把钱送回书店，书店可将我送上法庭，以便讨回欠款。该书店可拿出我签署的欠条，向法庭证明，我在2001年8月12日曾同意向他们支付10.00元的。
同一天，我还在网上书店当当处定购了一套我爱我家，书店收了我150元外加5.3元的邮寄费，我采用货到付款的方式。这个交易和我在我家附近的书店购买的差别在于,当当没有获得我签名的纸上协议。最后，当当公司把影碟送过来，我同样也支付了这笔钱。但是如果我拒绝支付，当当书店并没有我签署的协议证明我同意在2001年8月12日支付155.3元。如果我声称我从未买过那本书，当当书店只好白跑一倘了.
虽然准确的数字无法统计，当然也会随着商家的不同而不同，但是可能会有10%以下的因特网交易的帐单会因为信用卡诈骗和争议返回发生交易的商家。这是一个十分巨大的数字。消费商如当当只好接受这一结果，作为在网上做生意的成本和进入了定价时考虑的因素。但是很明显，这不适用于达到六位数字的商家与商家的交易。没有人会愿意送出 200,000元的共济金，只是为了让购买人来声称他们从未定过货也没有收到所定的货。在商家对商家的交易移到网络上之前，必须找出一种办法可以确认定货事实上已经由特定的人作出，而这个人就是他或她所声称的人。进一步说，这必须是在法庭上可强制实施的。
对这个问题的部分解决办法是数字签名纸上签名的电子等价物。为了在文档上进行电子签名，利用已有的算法计算出该文档的杂乱代码，将这个代码用私人密钥加密并将其附加在加了密的文档的杂乱代码上。通信人可以将杂乱代码用公开密钥解密，并对它是否与文档相匹配加以核对。但是，通信人不能代表别人在文档上签名，因为，他们没有别人的私人密钥。后面的准确的协议在实际上比较复杂，但是至少私人密钥要与被签名的文档以可核实的方式加以合并。其他不知道私人密钥的人都不能签署文档。
这种方案也不是没有漏洞例如当私人密钥被窃时也出现弱点但是要想伪造数字签名可能会像伪造纸上的签名一样困难。不过还是有一定数目的不太明显的对数字签名协议的攻击。最重要的事情之一是，改变签名的数据。改变签名的数据会使签名无效，但是，在第一步上，如果不让变化了的数据包括在内的话，也不会使数字签名失效。例如，当我们发送一个HTML表单时，送出的只是填入表单域中的值和域名。其余的HTML标记并不包括在内。我们同意为一台新的运行Windows NT的450MHz Pentium II PC机支付4500元，但是只发送表单中的1500元。对这个数字加以签名，表明支付了多少钱，但未对要买的东西签名。商家可寄来两箱康师傅方便面，并声称这就是顾客花1500元要买的东西。很明显，如果要使数字签名有用，交易的所有细节都要包括在签名内，不能漏掉任何内容。
如果要与政府部门(比如，海关，网上报税)打交道的话，事情会变得更糟。根据政府的采购定货单和申请规则，表单的内容往往写得非常详细，连所用的字形和字号都有严格的要求。如不遵守这些规格，就可能导致价值20,000,000元的发票作废。因而不仅需要说明同意什么，还需要说明满足了表单的各项法定要求。HTML表单还没有复杂到能够满足这些需要。
但是XML可以满足这些要求。总是可能利用XML来开发出一种结合了功能与准确性的标记语言，来满足各项要求。说得更确切一些，UWI.COM已经提出了一种名为扩展表单描述语言（Extensible Forms Description Language，简写为XFDL）的XML应用，可用于带有严格的法定要求并可用数字签名的表单。XFDL能够成为电子商务的关键部分.
人力资源标记语言HRML: HireScape公司的人力资源标记语言（Human Resources Markup Language，简写为HRML）是一种能够为描述工作职位空缺提供词汇表的XML应用。它将与典型的分类招聘广告相匹配的部分定义为元素，如公司、部门、招聘人员、联系信息、条款、经验以及其他各种项目。
以HRML写成的工作职位列表如下：
<?xml version="1.0"?>
<HRML_JOB>
<COMPANY>
<CO_NAME>IDG Books</CO_NAME>
<CO_INTERNET_ADD >
<CO_HOME_PAGE>http://www.idgbooks.com/</CO_HOME_PAGE>
<CO_JOBS_PAGE>
http://www.idgbooks.com/cgi-bin
/gatekeeper.pl?uidg4841:%2Fcompa y%2Fjobs%2Findex.html
</CO_JOBS_PAGE>
</CO_INTERNET_ADD >
</COMPANY>
<JOB>
<JOB_METADATA>
<JOB_LOADED_DT>09/10/1998</JOB_LOADED_DT>
<JOB_LOADED_URL>
http://www.idgbooks.com/cgi-bin
/gatekeeper.pl?uidg4841:%2Fcompa y%2Fjobs%2Findex.html
</JOB_LOADED_U L>
</JOB_METADATA>
<JOB_DATA>
<JOB_TITLE>Web Development Manager</JOB_TITLE>
<JOB_NUMBER_AVAIL>1</JOB_NUMBER_AVAIL>
<JOB_YEARS_EXP>3</JOB_YEARS_EXP>
<JOB_DESC>
This position is responsible for the technical
and production functions of the Online
group as well as strategizing and implementing
technology to improve the IDG Books web sites.
Skills must include Perl, C/C++, HTML, SQL, JavaScript,
Windows NT 4, mod-perl, CGI, TCP/IP, Netscape servers
and Apache server. You must also have excellent
communicatio skills, project management, the ability
to communicate technical solutions to non-technical
people and management experience.
</JOB_DESC>
<JOB_KEYWORDS>
Perl, C/C++, HTML, SQL, JavaScript, Windows NT 4,
mod-perl, CGI, TCP/IP, Netscape server, Apache server
</JOB_KEYWORDS>
<JOB_TERMS PAY="Salaried" TYPE="Full-time">
$60,000
</JOB_TERMS>
<JOB_LOCATION CITY="Foster City" STATE="California"
STATE_ABB ="CA" POSTAL_CODE="94404" COUNTRY="USA">
</JOB_LOCATION>
</JOB_DATA>
</JOB>
<RESPONSE>
<RESP_EMAIL>cajobs@idgbooks.com</RESP_EMAIL>
<POSTAL_ADDR ENTITY_TYPE="Response">
<ADDR_LINE_1>Dee Harris, HR Manager</ADDR_LINE_1>
<ADDR_LINE_2>919 E. Hillsdale Blvd.</ADDR_LINE_2>
<ADDR_LINE_3>Suite 400</ADDR_LINE_3>
<CITY>Foster City</CITY>
<STATE>CA</STATE>
<POSTAL_CODE>94404</POSTAL_CODE>
</POSTAL_ADD >
</RESPONSE>
</HRML_JOB>
用户当然能够为HRML定义样式单并用HRML将招聘职位列表放置在Web页面上。但这不是HRML的主要应用目的。HRML是为在公司、申请人、招聘人、招聘布告板和其他感兴趣的方面之间自动交换工作信息而设计的。在因特网上有数百个招聘布告板，还有无数的用户新闻组和邮件列表。对于个人来说，要想将其全部加以搜索是不可能的，对于计算机来说将其全部加以搜索也是困难的。因为这些布告板是使用不同的格式来描述工资、位置、福利以及类似项目的。
但是，如果许多站点都采用了HRML，那么对于寻找工作的人来说，要搜索带有搜索条件，如"在中关村的所有年薪高于100,000元的Java程序员"的结果就变得相对简单。而IRS可以输入一个搜索，查找所有的全日制工作的、在现场的、自由职业的空缺，从而了解哪些公司没有扣税也没有扣除失业保险。
实际上，这些搜索很可能通过HTML表单为中介，就像当前的Web搜索一样。主要差别是，这种搜索可以返回更详细的资料，因为这种搜索更有的放矢。
资源描述框架RDF: XML向文档中增加了结构。资源描述框架（Resource Description Framework ，简写为RDF）是一种增加语义的XML应用。RDF可以用来指定任何事情，从Web页面的作者和摘要到软件版本和依赖性，以及电影的导演、编剧和演员。连接所有这些应用的是，RDF编码不是数据本身（Web页面、软件、电影等）而是关于数据的信息。关于数据的数据称为元数据（meta-data），而这正是RDF存在的理由。
RDF词汇表定义了一套元素和它们允许的、对于给定领域的元数据来说是适当的内容。RDF使感兴趣的社区可以将词汇表标准化，并与其他可能会扩展词汇的人共享这些词汇。例如，Dublin Core是一个专为与Web页面有关的元数据设计的词汇表。Educom公司的指令元数据系统（Instructional Metadata System，简写为IMS）建立在Dublin Core的基础之上，但增加了附加的元素，这些元素当描述与学校有关的内容时，如学习等级、教育目的和价格等是非常有用的。当然，虽然RDF可用于印刷出版系统、视频店目录、自动软件更新和其他许多项目，但它好像首先会被用于在Web页面上嵌入元数据。RDF具有潜在的能力，可以目前"臃肿"的<META>标记（这种标记用于站点地图、内容评价、自动索引和数字图书馆等）与所有的工具都能"理解"的统一集合相同步。当RDF元数据成为Web页面标准的一部分时，搜索引擎将能够返回更为集中和有用的结果。智能代理可更为容易地搜索整个Web，以找出想要找的信息或是为我们进行交易。Web就会从当前的状态（无序的信息海洋）变成结构化的、可搜索的、可理解的数据保存地。
正如名称所暗示的，RDF描述资源。资源是可用URI来寻址的任何事物。资源的描述是由一系列属性组成的。每个属性具有类型和数值。例如，<DC:Format>HTML </DC:Format>的类型为DC:Format，而值为HTML。值可以是文本字符串、数字、日期以及其他类型的数据，也可以是其他资源。在RDF中，这些其他资源可以有自己的描述。例如，下面的代码使用了Dublin Core 词汇表来描述名为Cafe con Leche的 Web站点。
<RDF:RDF
xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax- s#"
xmlnsC="http://purl.org/DC/">
<RDFescription about="http://metalab.unc.edu/xml/">
<DC:Creator>Elliotte Rusty Harold</DC:Creator>
<DC:Language>en</DC:Language>
<DC:Format>HTML</DC:Format>
<DCate>1999-08-19</DC:date>
<DC:Type>home page</DC:Type>
<DC:Title>Cafe con Leche</DC:Title>
</RDFescription>
</RDF:RDF>
RDF将会用于Platform for Internet Content Selection （因特网内容选择平台，简写为PICS）2.0版和Platform for Privacy Preferences（隐私优选平台，简写为P3P）和许多需要用元数据来描述Web页面和其他种类内容的其他领域。
好了，上面我们说了很多关于XML如何突破HTML这种基本标记集的话题。其实，这个优势还远远不是XML的最大优势。那么，它的最大优势又是什么呢？
1.2.3 XML的第二大优势-超越固有格式
XML的最大能量来源于它不仅允许你定义自己的一套标记，而且这些标记不必仅限于对于显示格式的描述。XML允许你根据各种不同的规则来制定标记，比如根据商业规则，根据数据描述甚至根据数据关系来制定标记。
标准无法统一直是一个大问题，在不同软件中所留下的数据信息无法通用,使得信息的交换非常滞后, 软件不能胡乱加以改变。在一种给定的没有文档说明的专有格式中的数据越多，则越难以改变这种软件。例如，我过去五年的个人财务信息都保存在ACCESS中。即使SQL SERVER有的功能在ACEESS中没有，我也不会轻易地将其改变为SQL SERVER。除非SQL SERVER可以读取和转换ACCESS文件，而不损失任何数据。
在一个公司之内或是一个公司的产品之内也可能出现问题。Microsoft Word 97 for Windows不能读取Word的较早版本创建的文档。而早期版本的Word也不能读取Word 97 for Windows的文件，即使是Word 98 for the Mac比Word 97晚发行一年，也不能很好地读取Word 97 for Windows的文件。
使用给定格式的程序越多，在开发费用和精力上的节约也就越大。例如，六种程序要读写自己和互相读写其他程序的专有格式，需要有36种不同的转换器。当这六种程序都读写同样的XML格式时，只需要六种转换器，这样一来，开发上的精力减少为O（与n成正比），而不是原来的O(n2)（与n2成正比）。图1.1描述了六个程序读写自己和互相读写其他程序专有格式的情况。而图1.2描述了六种程序读写同样的XML格式的情况。每个箭头代表一种在程序间交换文件与数据的转换器。在图1.1中，我们可以看到对于六种不同的程序相互读写专有的二进制格式的连接。在图1.2可以看到同是这六种程序都读写一种开放的XML格式的连接。基于XML的交换要比二进制的交换简单得多也清楚得多。

图1.1 六种不同的程序读写自己的和互相的格式
图1.2 六种程序读写同一种XML格式
可能你还没有觉得这有什么好处。那好，还记得前面两节中那个关于F公司的客户列表的例子吗？现在，我们再来一起对两个不同的文件进行一个详细的比较。
当这个文件使用HTML语言写时，文件的样子如下：
<UL>
<LI>张三</LI>
<UL>
<LI>用户ID: 001</LI>
<LI>公司: A公司</LI>
<LI>EMAIL: zhang@aaa.com</LI>
<LI>电话: (010)62345678</LI>
<LI>地址: 五街1234号</LI>
<LI>城市: 北京市</LI>
<LI>省份: 北?lt;/LI>
<LI>ZIP: 100001</LI>
</UL>
<LI>李四</LI>
<UL>
<LI>ID: 002</LI>
<LI>公司: B公司</LI>
<LI>EMAIL: li@bbb.org</LI>
<LI>电话: (021)87654321</LI>
<LI>地址: 南京路9876号</LI>
<LI>城市: 上海市</LI>
<LI>省份: 上海</LI>
<LI>ZIP: 200002</LI>
</UL>
</UL>
尽管这也是一个存储、显示数据的可行的方法，它的效率和能力却非常有限。不知你是否已有同感，使用偏重于表现的HTML来描述你的数据有很多潜在的问题。我们至少可以看到以下三个严重的问题：
1.显示方式内嵌于数据之中可以看到：现在这些数据是用列表的形式来表示的。如果突然有一天，你的老板要求你用表格来表示这些数据，那么你不得不重新编码所有这样的HTML文件！天啊，这可能意味着几十页几百页要推翻重来啊！
2.在这些数据中寻找信息非常困难：如果有一天，你需要从这个网页中找到所有北京市客户的信息，你该怎么办？显然，如果你不打算手工寻找的话，你要编一个脚本程序，譬如JavaScript，VBScript。那么，你怎么编写这个程序呢？唯一可行的办法可能就是逐字寻找"北京"这个字符串。即便你找到了所有这些字段，恐怕你也还没有解决所有麻烦。这个"北京"是指城市还是指省份呢？（别忘了北京地区的周边郊县哦。）
3.数据自身的逻辑不得不屈服于HTML语言规范的逻辑：如果你想用Java Applet来处理你的数据，你又遇到了另一个麻烦。你的Java Applet将不得不遍历整个HTML文件，把所有的HTML标记剔除掉，再把剥离出来的有用的数据重新组织。同样，任何一个不是单纯为了显示HTML文件的应用程序，在处理一个HTML文件中的数据时，都不得不做大量额外的工作。
当使用XML时，以上的问题迎刃而解。
此时，这段信息的表示是这样的：
<联系人列表>
<联系人>
<姓名>张三</姓名>
<ID>001</ID>
<公司>A公司</公司>
<EMAIL>zhang@aaa.com</EMAIL>
<电话>(010)62345678</电话>
<地址>
<街道>五街1234号</街道>
<城市>北京市</城市>
<省份>北京</省份>
<ZIP>100001</ZIP>
</地址>
</联系人>
<联系人>
<姓名>李四</姓名>
<ID>002</ID>
<公司>B公司</公司>
<EMAIL>li@bbb.org</EMAIL>
<电话>(021)87654321</电话>
<地址>
<街道>南京路9876号</街道>
<城市>上海</城市>
<省份>上海</省份>
<ZIP>200002</ZIP>
</地址>
</联系人>
</联系人列表>
可以看出，现在标记为要表现的数据赋予了一定的含义。用这种形式存储时，数据非常地简单明晰，因为它所携带的信息不是显示上的描述，而是信息的语意。就象我们后面将要看到的那样，信息的显示方式已经从信息本身中抽取出来，放在了"样式单"中。
好，我们现在逐条看一下上面所说的XML的三个问题是如何被一一解决的
1.在XML中，显示样式从数据信息中抽取出来，放在样式单文件中。这样，如果需要改动信息的表现方式，无须改动信息本身，只要改动样式单文件就够了。如果这时候老板又让你把列表的数据改用表格显示，你无须再去修改那几十几百个数据信息文件，因为它们和同一个样式单文件相关联，只要改动这个样式单文件就足够了。
2.在XML中数据搜索可以简单高效地进行。搜索引擎没必要再去遍访整个XML文件，它只须去找一找相关标记下的内容就够了。也就是说，要想找"北京"，只要看看<城市〉这个标记下的字符串数据是不是匹配就行了。毫不夸张地说，XML的标记为搜索引擎赋予了智慧！
3.XML是自我描述语言。即便对于一个预先对我们的FCLML一无所知的人，这个文件也是清晰可读的。显然，<ID>002</ID>代表了一个客户的客户身份标识，可是如果面对一个<LI>002，他可能就无所适从了。再有，看看上面文件中严格的层次结构，你就会发现，信息之间的某些复杂关系，比如树状结构、继承关系，在这里也都得到了绝好的体现。这样一来，那些XML的应用处理程序也会感到轻松多了。
看到这里，你可能已经对XML心悦诚服了。不过，XML的优点还远不止这些哦。
1.2.4 XML的其他优点
前面讲到的XML的两大优势是XML最突出的优点，除此以外，XML至少还有下面三个优点。
1.XML遵循严格的语法要求
前面讲过，HTML的语法要求并不严格，浏览器可以显示有文法错误的HTML文件。但XML就不同了，它不但要求标记配对、嵌套，而且还要求严格遵守DTD的规定，比如在前面的client.xml中，你决不能在<联系人></联系人>这对标记外面，再套上一层<地址></地址>标记。
和HTML不同，XML非常非常注重准确性。如果语法有丝毫差错，分析器都会停止对它的进一步处理，相应地，除了错误提示外，你看不到任何的显示信息。
举例来说，对于任何一个XML文件，处理指示都是必须的。而如果一个HTML文件没有开始标记〈HTML〉，在大多数浏览器中仍能通过。因为浏览器通常具备一个内置的修改功能去猜测HTML文件中漏掉了什么，并试图修改这个有误的文件。"XML分析器，无论是内嵌于浏览器还是作为独立的处理器，绝对不允许修改。就象我们编译一个程序一样，一个XML文件或者被判别为’正确’而被接受，或者被判别为’错误’不予运行。这看上去可能有些武断，不过想想XML的宗旨在于通过非标准的标记传递结构化的数据，一个分析器无法象处理一个已有了一套固定DTD的HTML文件那样猜出到底有什么，又缺什么。
--Ken Sall"
一听说编写XML文件时要遵循严格的语法要求，那些被HTML宠坏了的网页制作者可能会叫苦不迭。其实仔细想想，一个具有良好语法结构的网页文件可以提供较好的可读性和可维护性，从长远来看还是大有好处的。何况这大大减轻了浏览器开发人员的负担，也提高了浏览器的时间空间效率。再有，以后随着XML的自动生成工具和所见即所得的编辑器的问世，XML的编写者也就不用再操心XML的源码是什么样子，更不用去想XML的一些琐碎的语法规定。当然，这对于这类XML的开发工具提出的要求可就比较高了。
2.XML便于不同系统之间信息的传输
当今的计算机世界中，不同企业、不同部门中存在着许多不同的系统。操作系统有NT、UNIX，数据库系统有SQL Server、Oracle，...，要想在这些不同的平台、不同的数据库软件之间传输信息，不得不使用一些特殊的软件，非常之不便。而不同的显示界面，从工作站、个人微机、到手机，使这些信息的个性化显示也变得很困难。现在有了XML，各种不同的系统之间可以采用XML作为交流媒介。XML不但简单易读，而且可以标注各种文字、图像甚至二进制文件，只要有XML处理工具，就可以轻松地读取并利用这些数据，使得XML成为一种非常理想的网际语言。
3.XML具有较好的保值性XML的保值性来自它的先驱之一--SGML语言。SGML是一套有着十几年历史的国际标准，它最初设计的一大目标就是要为文件提供50年以上的寿命。不要小看文件的寿命问题，想想我们是如何知道我们祖先的悠久而辉煌的历史的。如果不是流传至今的大量历史文献，我们恐怕?quot;唐宋元明清"没有一点概念；同样，我们的后代也要靠我们留下的文字资料来了解我们。可是现在大部分资料都是电子文档的形式了，有些人已经不屑于把它们打印下来单独存档，而只留一份拷贝就觉得万事大吉了。祸患的种子就是这样埋下的，假定五十年以后，你的子孙面对你留下的一大堆用Word97写的文档，苦于没有软件工具能够打开（你现在还能打开当初用WordStar1.0写的文件吗？），那么这一段历史岂不被抹煞了？如果没有XML，恐怕只有两个办法：要不返朴归真继续使用纸介质，要不不辞劳苦随着软件的更新换代来大规模地转换你的文档到最新的格式。幸好，20世纪末的科技先知对这一问题给出了圆满的解决，这就是SGML和XML的设计。它们不但能够长期作为一个通用的标准，而且很容易向其它格式的文件转化。想留下逝去岁月的印迹吗？XML是你明智的选择。
到现在为止，我们已经详细阐述了XML的五大优点。不过，任何事物都不是完美无缺的，XML也有一些固有的缺陷，虽然这些缺陷不是不可弥补的，但它在XML的阳光大道上，还是投下了一些小小的阴影。
1.2.5 XML的一点缺陷
前面说了XML的一大堆好话，希望已经说服大家，弃暗投明，在下一个网站开发计划中采用XML作为网页发布语言。要知道，XML可是国际标准化组织--国际互联网论坛W3C（World Wide Web Consortium）推荐的第二代网页发布语言啊！
不过这时可能又有人要问了："我好像还没有见过用XML发布网页的网站嘛！既然XML这么好，为什么从它第一个版本颁布至今，这么多年都没有推广普及开呢？"
这个问题的确问到了点子上。不错，XML固然好，但也有它不足的一面，阻碍了它的发展。而其中最大的不足，便是至今都没有什么能够充分支持它的应用处理程序。
想想看，HTML之所以在网络上如此流行，是因为你知道，如果你写了一个HTML文件，那么无论什么人在什么地方，他都能用IE或Netscape读出你的文件，欣赏你的布局。但是，如果你写的是一个XML文件，你可能就没那么有把握了。迄今为止，市场上没有一个可以完全支持XML的浏览器，虽然IE最近的版本IE5已经能够用XSL样式单将XML文件转化为一个HTML文件并显示出来，但这距离XML完全的显示输出还有很大距离。不过，对于XML所面临的这一难题，业界人士还是比较乐观的。
尽管目前浏览器对XML的支持还很有限，但IE5和Netscape5都预计要完全支持XML。不仅如此，目前W3C的Amaya浏览器也能支持它，就象JUMBO浏览器能够用来支持化学描述语言CML一样。
XML强调的并不是表现，而是文章本身的结构。这使得浏览器的角色在XML的使用上退居二线。至于究竟要表现哪些数据，以及如何表现，这是其它应用程序应该解决的问题。你可以把相同的XML文件和不同的样式单相连，从而使用不同的设备来表现，比如使用浏览器、手机、打印机、甚至音响设备。你不应该觉得只有等到有浏览器完全支持它以后，它才有用。绝不是这样--事实上，在没有使用任何浏览器的情况下，我们在NASA已经使它得到了充分的利用。
--Ken Sall
尽管XML所强调的的确远远超出了信息表现这一范畴，但是，对于广大网络浏览者来说，一段不能在浏览器中浏览的XML文件，对他们恐怕还是没多大意义。目前，解决XML浏览问题的方法有两种，一种是在传递XML文件之前先将它转换为一个HTML文件，然后再传输这个转换后的文件；还有一种是直接传递XML文件，显示时再在线地进行转换。
目前使用最多的方法，是用一个DHTML，或Java，或一个服务器端的perl写一个分析程序来分析XML文件，然后再把样式单中所描述的格式规则应用于这些分析提取出的XML数据，将它们转换为HTML文件。但是，采用这个方法，即便是要显示"hello world"这样简单的信息，也要历经周折。很多开发者也正是因此望而却步。
不过，随着越来越多的用户看到将他们的数据用XML组织的好处后，相信XML的分析算法和相应的工具也会逐渐完善起来，XML的后端支持将变得越来越简单。从IE和Netscape所提供的内置XML分析工具中，我们还是看到了无限希望嘛！
1.2.6 HTML与XML之比较
通过前面这一番比较讲解，相信大家已经不会再把XML和HTML混为一谈了。不过初学者问得最多的问题就是XML与HTML有什么不同，鉴于这一点，我们再来列表把它们进行一个详细的比较。
比较内容 HTML XML
可扩展性 不具有扩展性 是源描述语言，可用于定义新的描述语言
侧重点 侧重于如何表现信息 侧重于如何结构化地描述信息
语法要求 不要求标记的嵌套、配对等，不要求标记之间具有一定的顺序 严格要求嵌套、配对，和遵循DTD的树形结构
可读性及可维护性 难于阅读、维护 结构清晰，便于阅读、维护
数据和显示的关系 内容描述与显示方式整合为一体 内容描述与显示方式相分离
保值性 不具有保值性 具有保值性
编辑及浏览工具 已有大量的编辑、浏览工具 编辑、浏览工具尚不成熟
1.3 XML的背景介绍
1.3.1 XML语言发展历史
好啦，现在让我们来回顾一下XML的发展简史。
XML有两个先驱--SGML和HTML，这两个语言都是非常成功的描述性语言，但是他们都在某些方面存在着与生俱来的缺陷。XML正是为了解决它们的不足而诞生的。
让我们首先从SGML说起。SGML的全称是标准通用化描述语言，它从80年代初开始使用。正如XML一样，SGML也可用于创建成千上万的描述语言，它为语法描述提供了异常强大的工具，同时具有极好的扩展性，因此在分类和索引数据中非常有用。目前，SGML多用于科技文献和政府办公文件中。
但是，SGML非常之复杂，其复杂程度对于网络上的日常应用简直不可思议。不仅如此，SGML非常昂贵。目前比较便宜的SGML软件之一是Adobe FrameMaker，其标准版本价格为850美元，而Adobe FrameMaker+SGML是以1995美元售出的。还有最关键的一点，几个主要的浏览器厂商都明确拒绝支持SGML，这无疑是SGML在网上传播遇到的最大障碍。
相反，HTML免费、简单，而且它获得了广泛的支持。HTML最初于1990年由CERN设计，它是一个非常简单的SGML语言，可以方便普通人的使用。而正如设计之初所构想的那样，HTML现在在世界范围内得到了广泛的应用。不幸的是，HTML有许多致命的弱点，正如我们前面所分析的那样。
正因为如此，1996年人们开始致力于描述一个新的描述语言，它既具有SGML的强大功能和可扩展性，同时又具有HTML的简单性。国际互联网论坛W3C（World Wide Web Consortium）决定专门成立一个SGML专家小组来从事此项工作，大名鼎鼎的Sun公司的Jon Bosak担任小组的指挥。
事实上，Bosak和他领导的专家小组对SGML所做的贡献就象JAVA研究组对C++做出的贡献一样。SGML中所有非核心的、未被使用的和含义模糊的部分都被删除，剩下的就成为短小精干的描述性工具--XML。对于XML的描述（由Tim Bray和C.M. Sperberg-McQueen撰写）只有26页，而当初的SGML的描述却长达500页之多。而更妙不可言的是，尽管篇幅只是SGML的1/20，但SGML中所有的精华都被保留了下来。
这以后，XML不断发展演化，并且从CML和MathML中汲取了大量的经验。1997年春天，可扩展链接语言XLL草案已被拟定，到了1997年夏天，微软也开始了关于通道描述格式CDF（Channel Definition Format）的定义工作，这应该算是XML的第一个真正的应用。
最后，XML于1998年修成正果。W3C于1998年2月批准了XML的1.0版本，一个崭新而大有前途的语言诞生了。
1.3.2 描述语言一览
自从XML诞生以来，又有一大批用XML定义的新的描述语言随之诞生，它们有的仍处在草案阶段，还有一些已经由W3C推荐成为正式标准，开始在各个领域发挥着它们、同时也是XML的巨大优势。这其中包括前面说到的CML和MathML，还包括使用XML重新定义的XHTML，用于显示矢量图形的SVG，用于表现多媒体效果的SMIL，用于电子书的OEB，用于手机上网的WML和HDML，面向电子商务的cXML，等等等等，不一而足。这些描述语言家族的新成员，我们将在后面再具体介绍。
最后，让我们来看看描述语言这个大家族的家谱表：


1.4 XML示例
哈哈，看了这么多枯燥的原理论述，你是不是已经不耐烦了。好，现在就让我们再把刚才关于客户联系列表的例子完整地看一遍。通过这个例子，相信你将对XML的整体机制有一个大致的了解。
在1.1.2节，我们为我们的描述语言FCLML制定了下面的DTD：
fclml.dtd：
<?xml version="1.0" encoding="GB2312"?>
<!ELEMENT 联系人列表 (联系人)*>
<!ELEMENT 联系人 (姓名,ID,公司,EMAIL,电话,地址)>
<!ELEMENT 地址 (街道,城市,省份)>
<!ELEMENT 姓名 (#PCDATA)>
<!ELEMENT ID (#PCDATA)>
<!ELEMENT 公司 (#PCDATA)>
<!ELEMENT EMAIL (#PCDATA)>
<!ELEMENT 电话 (#PCDATA)>
<!ELEMENT 街道 (#PCDATA)>
<!ELEMENT 城市 (#PCDATA)>
<!ELEMENT 省份 (#PCDATA)>
关于客户联系信息的标准XML文件是这样的：
client.xml
<?xml version = "1.0" encoding="GB2312" standalone = "no"?>
<!DOCTYPE 联系人列表
SYSTEM "fclml.dtd">
<?xml-stylesheet type="text/xsl" href="mystyle.xsl"?>
<联系人列表>
<联系人>
<姓名>张三</姓名>
<ID>001</ID>
<公司>A公司</公司>
<EMAIL>zhang@aaa.com</EMAIL>
<电话>(010)62345678</电话>
<地址>
<街道>五街1234号</街道>
<城市>北京市</城市>
<省份>北京</省份>
</地址>
</联系人>
<联系人>
<姓名>李四</姓名>
<ID>002</ID>
<公司>B公司</公司>
<EMAIL>li@bbb.org</EMAIL>
<电话>(021)87654321</电话>
<地址>
<街?gt;南京路9876号</街道>
<城市>上海</城市>
<省份>上海</省份>
</地址>
</联系人>
</联系人列表>
可能你已经注意到，文件的前三行在前面并没见过。第一行称作处理指示。以后我们还会再详细谈到处理指示和它们的属性。现在，我们只须知道凡是XML文件都需要这样一行，就象HTML文件都需要用〈HTML〉开头一样。第二行指定了和该XML文件相连的样式单文件，第三行则指定了和它相连的DTD文件。
下面，我们需要将不同的样式赋予各个标记，以便浏览器来显示数据。象我们前面所说的，XML允许你创建自己的标记集，因此，你必须创建你自己的样式指示，这样，浏览器就可以通过这些指示来显示它从未见过的标记下的内容。
因为样式单是独立于数据的，同一个样式单可以由许多XML文件共享。而且，样式单可以用不同的样式语言来描述，例如使用层叠式样式单语言CSS（Cascading Style Sheet Language），或者使用可扩展样式语言XSL（eXtensible Style Language）。在这个例子中我们使用XSL。
现在我们为client.xml制定一个样式单：
mystyle.xsl
<?xml version="1.0" encoding="GB2312"?>
<xsl:stylesheet xmlns:xsl=http://www.w3.org/TR/WD-xsl
xmlns=http://www.w3.org/TR/REC-html40
result-ns="">
<xsl:template><xsl:apply-templates/></xsl:template>
<xsl:template match = "/">
<HTML>
<HEAD>
<TITLE>F公司的客户联系信息</TITLE>
</HEAD>
<BODY>
<xsl:apply-templates select="联系人列表"/>
</BODY>
</HTML>
</xsl:template>
<xsl:template match = "联系人列表">
<xsl:for-each select="联系人">
<UL>
<LI><xsl:value-of select="姓名"/></LI>
<UL>
<LI>用户ID:<xsl:value-of select="ID"/></LI>
<LI>公司: <xsl:value-of select="公司"/></LI>
<LI>EMAIL: <xsl:value-of select="EMAIL"/></LI>
<LI>电话: <xsl:value-of select="电话"/></LI>
<LI>街道: <xsl:value-of select="地址/街道"/></LI>
<LI>城市: <xsl:value-of select="地址/城市"/></LI>
<LI>省份: <xsl:value-of select="地址/省份"/></LI>
<LI>ZIP: <xsl:value-of select="地址/ZIP"/></LI>
</UL>
</UL>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
好了，我们已经完成了XML和它相关的DTD、XSL文件，处理器会根据DTD来检查XML的语法，然后再根据XSL的指示显示这些信息。在后面，我们还会详细地叙述处理的过程。现在，你只需知道这个XML文件被样式单转换为下面的HTML文件（有点麻烦，不过你很快就会习惯的）：
<HTML>
<HEAD>
<TITLE>F公司的客户联系信息</TITLE>
</HEAD>
<BODY>
<UL>
<LI>张三</LI>
<UL>
<LI>用户ID: 001</LI>
<LI>公司: A公司</LI>
<LI>EMAIL: zhang@aaa.com</LI>
<LI>电话: (010)62345678</LI>
<LI>地址: 五街1234号</LI>
<LI>城市: 北京市</LI>
<LI>省份: 北京</LI>
<LI>ZIP: 100001</LI>
</UL>
<LI>李四</LI>
<UL>
<LI>ID: 002</LI>
<LI>公司: B公司</LI>
<LI>EMAIL: li@bbb.org</LI>
<LI>电话: (021)87654321</LI>
<LI>地址: 南京路9876号</LI>
<LI>城市: 上海市</LI>
<LI>省份: 上海</LI>
<LI>ZIP: 200002</LI>
</UL>
</UL>
</BODY>
</HTML>
你所看到的显示结果，实际上同上面这个HTML文件的显示结果是相同的
张三
用户ID: 001
公司: A公司
EMAIL: zhang@aaa.com
电话: (010)62345678
地址: 五街1234号
城市: 北京市
省份: 北京
ZIP: 100001
李四
ID: 002
公司: B公司
EMAIL: li@bbb.org
电话: (021)87654321
地址: 南京路9876号
城市: 上海市
省份: 上海
ZIP: 200002
有兴趣的读者可以把上面这三个文件拷在一个目录中，然后用IE5打开文件client.xml，看看结果是不是这样。


2.1 关于XML的基本形式
　　HTML有大约三百个不同的标记，大多数标记又有相当多的标签，每个标签还有几种、十
几种不同的取值。乍一想起来，XML比HTML更加强大，所以你可能觉得它会有更多的标记。
其实不然，XML预定义的标记数目近乎为0。
--Elliotte Rusty Harold（注：其实HTML中只有90多个标记，Harold有点夸张了。）
　　读过前面一章后，相信大家对这段话都会有一个深刻的理解。恰如我们前面所讲的XML是
一个源描述性语言，可以看作是用来产生标识的工具。因此，XML并没有预定义一个特定的标
识集，而是描述了一个用来定义标识集的方法。当我们用这个方法规定好一个标识集，并根
据这些规定填入文本内容后，这些标记就和纯文本一起构成了一个XML文件。
　　从一开始起，我们就一直在讲XML"文件"如何，不过需要指出，使用"文件"这个词可能会
造成误导。XML标记语言除了能够放在通常意义的文件中以外，还能够按照数据流、数据库结
果集、以及由应用程序动态产生的结果而进行传送。因此，我们所说的XML文件实际上是广义
的文件，更准确的叫法应该是一个"数据对象"（如果您学习过编程语言，比如C，你可以把很
容易理解这个定义），但是为了简便起见，我们仍称它为"文件"。
　　尽管XML允许你"随心所欲"地建立你自己的标记集（后面一章我们会讲到建立标记集所要
遵循的种种规则），一旦这个标记集建立起来，你就不能再那么"随心所欲"地写你的XML文件
了，你必须严格遵守XML的语法和你自己的标记集的规定。当一个XML文件呈交给一个XML处
理程序时，为了保证处理程序能够很好地理解它，XML必须遵守XML的语法标准。最起码的，
这个XML文件应该是"形式良好的"（well-formed）。否则，处理程序将会不知所措，无法再
进一步进行下去，这时你能得到的全部结果，也只不过是一个"致命错误"的抱怨而已。
　　在XML中，"形式良好"有着明确的标准，即是要遵守XML1.0规范中的语法规则。无论是
从物理结构上讲，还是从逻辑结构上讲，XML都必须符合规范，才能被正确解释处理。可能刚
刚看到这里，你就已经被吓坏了。干嘛要那么多语法限制，现在不是都讲究"鲁棒性"吗？别
忘了XML制定的本意。XML创建之初的目标就是希望XML文件既容易被人阅读，又容易被机器
理解。为人设计一个可读的语言尚且容易，因为经过多年的磨练，人们似乎擅于理解一个不
严格遵守文法的，甚至有歧义的XML文件。但机器可没有那么智能化，如果文法不是很明确，
或者一个文件没有遵守文法，那机器就无法处理了。所以，确保你的文件是“形式良好的”，
这是一个最低标准，符合了这个标准，就能保证连最笨的机器也能阅读你的XML文件了。这一
章里，我们就来详细讲述这些最低标准。语法中的条条框框总显得枯燥乏味，不过正是它们
保证了XML严密的条理性、逻辑性和良好的结构性，XML的优点也正是依靠它们体现出来的。
2.1.1 创建你自己的第一个XML文档
　　本节遵照老程序员介绍新语言的传统，先用一个能够在屏幕上打印出"Hello World"的
程序加以介绍。XML是标记语言，而不是编程语言，但是基本原理还是适用的。最简单的方法
是以一个完全的可运行的有扩展能力的示例开始，而不要尝试以更基本的无任何功能的程序
开始。如果用户在使用基本的工具时确实遇到了问题，在简短的文档环境中也比在复杂的文
档环境下更容易调试和改正。
　　在本节中，读者将学到如何创建一个简单的XML文档并将其保存在文件中。然后我们对其
中的代码及其意义再加以仔细考察。
2.1.1.1 创建文档
　　在本节中，读者将学到如何键入一个实际的XML文档。我们从能够想像得到的最简单的XML文档开始。这个程序代码列在下面：
Hello XML
<?xml version="1.0" standalone="yes"?>
<FOO>
Hello XML!
</FOO>
　　这虽然不太复杂，但却是一个"好"的XML的文档。更准确地说，这是一个结构完整的XML
文档（XML中有一些用于文档的专门术语，依照到底满足了哪条规则而被认为是"好"的 。其
中"结构完整的"就是一条这样的术语，在本书的后面要对此加以讨论。）可在任何使用方便
的文本编辑器，如Notepad、BBEdit或是emacs中键入这个文档。
2.1.1.2 保存XML文档
　　当键入了上面的代码之后，请将该文档保存在名为hello.xml的文件中。也可以使用诸
如HelloWorld.xml、MyFirstDocument.xml或是其他文件名，但三个字母的扩展名.xml是
标准的，一般不要更改。而且还要确保以普通的文本格式加以保存，而不要用某些字处理程
序，如WordPerfect或Microsoft Word的内建格式。
　　如果使用的是Windows 95/98上的Notepad来编辑文件，当保存文档时，一定要将文件名
用双引号括起来，即"Hello.xml"，而不要只是Hello.xml，正如图2.1所示的一样。如果没
有引号，Notepad会在文件名后再加上.txt扩展名，也就是文件名变成了Hello.xml.txt，
这完全不是我们所希望出现的。

图2.1 在Notepad中用带引号的文件名来保存XML文档
　　Windows NT版本的Notepad还会给出将文件保存为Unicode格式的选项。令人惊奇的是，
这样保存也可以，不过我们还是坚持使用基本的ASCII文本格式比较好。XML文件既可以是
Unicode格式也可以是Unicode的名为UTF-8的压缩版本，这是严格的ASCII的超集，因而纯
ASCII文件也是合法的XML文件。
2.1.1.3 在浏览器里浏览
　　既然已经创建了第一个XML文档，当然想看一看了。这个文件可以在支持XML的浏览器，
如Internet Explorer 5.0中直接打开。图3.2显示的就是结果。
　　我们看到的结果将依不同的浏览器而有所不同。在本例情况下，文件是格式化得很好的，
以不同的颜色来表示不同的句法。不过所看到的并没有吸引人的地方。问题在于浏览器并不
了解如何来处理FOO元素。我们必须指示浏览器如何来处理每个元素，这就要用到样式单了。
我们将要简单地介绍一下，但首先还是仔细地考察一下这个文档。

图3.2 hello.xml在Internet Explorer 5.0中的显示结果
2.1.2 分析第一个XML文档
　　让我们分析一下列在2.1.1.1中的这个简单的XML文档，以便更好理解每行代码的意义。
第一行是XML声明：<?xml version="1.0" standalone="yes"?>这是XML处理指令的例子。
处理指令以<?开始，而以?>结束。在<?后的第一个单词是处理指令名，在本例中是xml。
　　XML声明有version和standalone两个特性。特性是由等号分开的名称-数值对。位于等
号左边的是特性名，而其值位于等号的右边，并用双引号括起来。
　　每一个XML文档都以一个XML声明开始，用以指明所用的XML的版本。上例中，version
特性表明这个文档符合XML 1.0规范。XML声明还可以有standalone特性，这告诉我们文档
是否在这一个文件里还是需要从外部导入文件。在本例中，以及在以后的几章中，所有的文
档都在一个文件里完成，因而standalone特性的值要设置为yes。
现在让我们看一下程序中的下面的三行：
<FOO>
Hello XML!
</FOO>
　　总体上说，这三行组成了FOO元素。分开说，<FOO>是开始标记，而</FOO>是结束标记，
Hello XML!是FOO元素的内容。读者可能要问，<FOO>标记的意义是什么？回答是"你要让它
是什么就是什么"。除了几百个预定义的标记之外，XML还允许用户创建所需的标记。因而
<FOO>标记可以具有用户赋于的任何意义。同一个XML文档可以用不同的标记名编写，正如下
面的代码所表明的：
greeting.xml
<?xml version="1.0" standalone="yes"?>
<GREETING>
Hello XML!
</GREETING>
paragraph.xml
<?xml version="1.0" standalone="yes"?>
<P>
Hello XML!
</P>
document.xml
<?xml version="1.0" standalone="yes"?>
<DOCUMENT>
Hello XML!
</DOCUMENT>
　　这四段代码用的标记名各不相同，但都是等价的，因为具有相同的结构和内容。我在这
里只是简单的举了一个例子,下面开始详细的介绍XML的文件结构。
2.2 XML与HTML文件的逻辑形式
2.2.1 XML文件的整体结构
　　XML文件的结构包括逻辑结构和物理结构。在这一节里，我们首先来看一看XML文件的逻辑结构。下面是一个例子，它是有关专有名词解释的XML文件：
[1] <?xml version="1.0" encoding="GB2312" standalone="no"?>
[2] <?xml-stylesheet type="text/xsl" href="mystyle.xsl"?>
[3] <专有名词列表>
[4] <专有名词>
[5] <名词>XML</名词>
[6] <解释>XML是一种可扩展的源置标语言，它可用以规定新的置标规则，并根据这个规则组
数据</解释>
[7] <示例>
[8] <!-- 一个XML的例子 -->
[9] <![CDATA[
[10] <联系人>
[11] <姓名>张三</姓名>
[12] <EMAIL>zhang@aaa.com</EMAIL>
[13] </联系人>
[14] ]]>
[15] </示例>
[16] </专有名词>
[17]</专有名词列表>
　　一个XML文件最基本的构成是
? XML声明
? 处理指示（可选）
? XML元素
在本例中，[1] 是一个XML声明，[3]--[17] 是文件中的各个元素。
除此以外，上面例子中出现的其它逻辑要素还有：
[1][2] 是处理指示
[8] 是注释
[9]--[14] 是CDATA
在[5]行的"<名词>XML</名词>"中，"<名词>""</名词>"是标记，"XML"是字符数据。
下面几个小节中，我们就来详细讲述这些逻辑要素和与它们相关的语法规则。
2.2.2 用XML声明作为开头
　　当你开始着手写一个XML文件时，最好以一个XML声明作为开始。之所以说"最好"，是因
为XML声明在文件中是可选内容，可加可不加，但W3C推荐加入这一行声明。因此，作为一个
良好的习惯，我们通常把XML声明作为XML文件的第一行。
　　XML声明是处理指示的一种，处理指示比较复杂，我们将在2.2.6节中再详细讲述。不过
XML声明相对简单一些，形象地说，它的作用就是告诉XML处理程序："下面这个文件是按照
XML文件的标准对数据进行置标的"。
　　一个最简单的XML声明是这样的：<?xml version = "1.0"?>
　　象所有处理指示一样，XML声明也是由"<?"开始，"?>"结束。在"<?"后面紧跟着处理指
示的名称，在这里是"xml"。XML声明中要求必须指定"version"的属性值。同时，声明中还
有两个可选属性，分别是"standalone"和"encoding"。因此，一个完整的XML声明是这样的
<?xml version = "1.0"
standalone = "no"
encoding = "GB2312"?>
下面，就让我们来看看这几个属性的具体含义：
　　? version属性：刚才我们提到，在一个XML的处理指示中必须包括version属性指明所
采用的XML的版本号，而且，它必须在属性列表中排在第一位。由于当前的XML最新版本是
1.0，所以我们看到的无一例外的都是：version = "1.0"。
　　? standalone：属性这个属性表明该XML文件是否和一个独立的置标声明文件配套使用。
因此，如果该属性置为"yes"，说明没有另外一个配套的DTD文件来进行置标声明。相反，如
果这个属性置为"no"，则有可能有这样一个文件。（注意，也可能没有。）
　　? encoding属性：所有的XML语法分析器都要支持8位和16位的编码标准。不过，XML可
能支持一个更庞大的编码集合。在XML规范的4.3.3节中，列出了一大堆编码类型。但一般我
们用不到这么多编码，只要知道下面几个常见的编码就可以了：
简体中文码：GB2312
繁体中文码：BIG5
西欧字符： UTF-8
　　采用哪种编码取决于你文件中用到的字符集。尤其要注意的是，在前面的例子中，我们
看到标签是可以用中文来写的，这时你务必要在声明中加上encoding = "GB2312"的属性。
（未完待续）
www.frontfly.com 放飞网

偶不学

现在语言都需要是跨平台的,通用的,xml也是为了往这方向发展的
入门教程可以在www.2tigers.net里找到

to eagleblue:请继续,谢谢!!!

xml 不得不学的～

我正拭目以待……

好文章，有内涵，堪称IT的陶行知

快晕了 幸亏我用惯了手写html xml应该更简单才是

up

gz

学习