曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
• 比起D T D许可，更加准确、灵活地描述词汇表。
• XML里的“读”词汇表规则，允许访问词汇表定义，而不用增加解析器的难度。
1 9 9 9年1月1 4日，XML 命名空间达到了W 3 C推荐的程度。模式正在通过标准的方法开展工
作，但很快就需要一种推荐说明书。这种对模式的需求在应用开发团体里非常强大，以至于模
式支持的技术调研小组开始安装解析器。这是由于为了应付推荐书出来之后模式快速的转换，
模式草案准备得足够值得推敲。
7.1 混合词汇表
回忆一下我们在第3 章见过的图书目录D T D 。在建立一个站点之后，用X M L 写成
P u b C a t a l o g . d t d词汇表，发布作品目录，你可以决定在线出售作品。这意味着需要能够为目录里
的书籍编排顺序。因此，需要一个D T D来研究书籍的顺序。
如果继续按照D T D章节提到的去做，你可能会添加到P u b C a t a l o g . d t d文件，这是因为这两个
范围标明了同一个问题—共享书籍数据的不同部分。但它们也可以看作不同的问题领域，这
是因为一个标明了目录的整体，而其他的标明了目录里的销售款项。当被这两部分传递的信息
里有一些重迭，而你又想通过一个D T D去研究两个领域，就会以被一大堆复杂的D T D所迷惑而
告终。
庞大并且包含很多主题信息的D T D很难让程序员阅读和理解。更重要的是，如果你已经在
产品里使用了目录D T D，D T D的改变可能会影响应用程序。但是这里有更好的解决方案，即融
合利用命名空间的单一文档中与各个目录、表单D T D保持一致的数据，因此我们将研究这种可
192使用XML 高级编程
下载
能性。但先让我们从近处看一下你面临的问题。
7.1.1 分解问题
首先，你为什么愿意用目录D T D混合表单的细节呢？至少有两个问题值得讨论，一个是所
有书籍的目录，另一个是每个题目的出售情况。当你考虑正在写一个大的程序，会把整个问题
分解成细小的问题。一些结构程序语言按照这种意图提供了模块、类、组件、包、函数等。设
计词汇表可以看作与编程类似的问题。你总是要将一个大的问题分解成多个词汇表。但是我们
必须要克服的问题其实并不是写每个D T D去描述许多词汇表，我们在第3章已经看到怎样能做到
这一点。如果我们将定义分解成目录和索引D T D（order DTD）的话，真正的问题存在于整合
D T D进一个文档的实体。
7.1.2 重用
在P u bCa t a l o g . d t d里我们使用了B O O K元素。某种程度上，在标记描述元素内容的数据的过
程中，这些做得相当完美。但是由于我们想要实现在线定书，当涉及到顾客想要订购的书籍时，
很可能还想使用相同的元素名称。的确，两者很有可能用不同的D T D来描述。毕竟表单里的
B O O K元素可能是表单元素的子级，因此，在P u bCa t a l o g . d t d里这是一个子C ATA L O G。
正如我们已经建议的，这是一个在创建X M L词汇表时反复出现的问题。在描述真实世界概
念时，我们将要不断地发现存在着的普遍结构。毕竟，复杂的创作是从简单的建筑元素—比
如颜色、形状、价格和尺寸，简单的事物不能长时间不定义，于是这里将有很多元素名称的实
例，他们已经有了定义和内容模型。
无论是你还是别人，用这些元素创建了一个D T D，借鉴已经被证明的D T D，你的任务将变
得更加容易（的确，对于处理词汇表里已经定义的结构的代码是可以利用的）。这就是重用的含
义。
即便你在为一个公司做计划，可能被现有的D T D所困扰。实际上，借鉴它们可以使你的工
作变得更简单，而忽视它们会另每个人的工作很难办，这是由于因为程序员的参与， D T D代表
了一种特定集合内的智力投资。正如其他人知道的，这些D T D描述了业务问题。在真实的生活
中，建立于与我们的这些例子里的书籍相关的D T D意味着你的任务是去扩展它，这在某种程度
上是当前已经知道和定义了的概念的延续。
的确，如果你正在编写一个应用程序并和其他合作伙伴的程序进行连接，除了重用现有的
感念之外，没有别的选择。使用中的D T D已经形成了一种你为了理解而去讲的通用语言。无论
什么时候概念存在，你都应该努力按照概念去理解。
已有定义的使用者正在努力地扩展它们并进行初始化。劝说别人去适应你的关于这个问题
的观点可能非常困难。即便你能够完成这项壮举，也应该认识到建立新的定义和代码和从现有
的D T D规划你的新内容相比会付出额外的代价。重用节省时间、人力和资金。
7.1.3 多义性名称冲突
不论你是重用其他设计者的D T D的定义，还是将离散的D T D连接起来去生成一个描述符合
第7章命名空间和模式使用193 下载
问题的文档，如果正在使用的文档里采用相同名称的元素，你都会冒多义性名称冲突这一问题
的风险。比如书是一个非常好的概念。你可以确定这里有几个D T D声明了“ B O O K”这个元素，
至少有出版商、印刷商、零售商和图书馆等。在文档里单一使用B O O K名称需要一个约定，即
要与合适的B O O K元素声明相匹配。在我们的例子里， B O O K是一个对目录和表单都通用的名
称。
一个用P u b C a t a l o g . d t d做标记的文档可能包括了下面这些对< B O O K >元素的使用：
程序清单7 - 1
因此一个关于书的表单可能需要像下面那样使用< B O O K >元素：
程序清单7 - 2
如果我在读一个X M L文档中包含来自两种词汇表的数据，那么怎么知道它指的是哪一种定
义呢？
当你从多个D T D把名称实例拿过来使用的话，问题变得严重了。假如我们有一个土木工程
师参与市政规划的应用程序。当谈到照明，我们为了交通灯和街灯而需要利用已有的D T D。各
自独立工作，每个词汇表设计者都会选择< L i g h t >这个词来作为元素的名称。如果他们知道了最
终应使用他们自己的D T D，他们就会选择< Tr a ff i c S i g n a l >和< S t r e e t L a m p >，但在D T D写入时，未
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
XML高级编程上(70)
