---

3.3.1 融众多元素命名于一体


学了DTD又学Schema，忙得大家不亦乐乎。但回过头来看看本章的标题，或许读者要奇怪了，“海纳百川”，可“海”指的是什么？“川”又是什么？它们和DTD与Schema有关系吗？现在我们就来详详细细地讨论我们的“海”与“川”，“海”就是XML文件，“川”就是由DTD或者Schema进行的元素类型声明，而“海纳百川”便是说我们在同一个XML文件中可以使用多个DTD或Schema声明的元素类型。
前面我们讲到，XML较之HTML最根本的差别在于XML是定义置标语言的元语言，而HTML仅仅是由SGML元置标语言定义的一个实例语言。利用XML元置标语言，定义各种各样的XML实例的活动是相当开放的。针对不同的应用方向，每设计一个XML的DTD，一种新的置标语言便随之诞生。在各种各样XML实例置标语言如雨后春笋般不断涌现的过程中，将会产生这样一种应用需求，即在一个XML文档中，包含由多个DTD描述的元素。这个想法显然是达到“物尽其用”的一个好办法，它帮助我们最大程度地利用了现有的资源，正所谓“海纳百川，有容乃大”。
但是，这条锦囊妙计也会带来一定的问题。仍拿我们前面使用过的"联系人列表"的例子来说，现在我们需要知道每个联系人的直接上级，以便业务的顺利开展。于是，DTD中要为“联系人”元素增加一个子元素“直接上级”。修改后的DTD文件命名为“联系人列表.dtd”，源码如下：

<ELEMENT 联系人列表 (联系人)*>
<ELEMENT 联系人 (姓名,ID,公司,EMAIL,电话,地址，直接上级)>
<ELEMENT 地址 (街道,城市,省份)>
<ELEMENT 姓名 (#PCDATA)>
<ELEMENT ID (#PCDATA)>
<ELEMENT 公司 (#PCDATA)>
<ELEMENT EMAIL (#PCDATA)>
<ELEMENT 电话 (#PCDATA)>
<ELEMENT 直接上级 ANY>
<ELEMENT 街道 (#PCDATA)>
<ELEMENT 城市 (#PCDATA)>
<ELEMENT 省份 (#PCDATA)>
至于"直接上级"的内容，也就是这个元素的子元素，来自于另一个DTD声明，即"企业经理"的DTD声明。这个声明“企业经理.dtd”的文件为：

<ELEMENT 企业经理 (姓名,电话)>
<ELEMENT 姓名 (#PCDATA)>
<ELEMENT 电话 (秘书电话，手机)>
<ELEMENT 秘书电话 (#PCDATA)>
<ELEMENT 手机 (#PCDATA)>
这样一来，我们的"联系人列表"的例子可能会写成下面的样子：
<联系人列表>
<联系人>
<姓名>张三
001
<公司>A公司
zhang@aaa.com
<电话>(010)62345678
<地址>
<街道>五街1234号
<城市>北京市
<省份>北京

<直接上级>
<姓名>王五
<电话>
<秘书电话>(010)62345678
<手机>13601234567




在这个例子中，“联系人”中有“姓名”和“电话”元素，而“直接上级”中也有“姓名”和“电话”元素。可是此“姓名”非彼“姓名”，此“电话”也非彼“电话”。尤其是“电话”元素，它们在语法语义上都是完全不同的。“联系人”元素中的“电话”子元素就是一个表示他电话号码的字符串，以方便与其联系；可是他的上级官职显要，电话的信息也比较多，包括秘书的电话和他的手机。对于XML文件的编写者和读者来说，凭借上下文的提示，对于这个差别尚能理解；但计算机可没有人那么聪明，面对两个“姓名”元素，它不知道哪个是“联系人列表”的DTD中定义的“姓名”，哪个又是“企业经理”的DTD中定义的“姓名”；它更会奇怪：“电话”怎么会摇身一变，成了“秘书电话”和“手机”的父元素？在这种情况下，我们称两个不同的元素在名称上发生了冲突。
如果不解决这种元素名称上的冲突问题，一个XML文档包含多个DTD中定义的元素这一天才构想就不能实现。为了解决这个问题，W3C的XML小组制定了被称为命名空间（NameSpace）的标准。W3C组织于1998年2月提出命名空间标准的第一个草案，到1999年1月14日正式发布为推荐标准。本章中介绍的命名空间，依照的就是这个推荐标准。

---