XML 架构快速指南.docVIP

XML 架构快速指南 发布日期： 4/1/2004 | 更新日期： 4/1/2004 Aaron Skonnard XML 文件存档 下载本文的代码：XML0204.exe (35KB) 在 所有的 XML 技术中，XML 架构对软件开发人员最具价值，因为是它最终使在 XML 文档中加入类型信息成为可能。本专栏是介绍 XML 架构基础知识的两部分系列文章中的第一部分。 首先，我们来回顾一下 XML 架构之前的知识。XML 1.0 规范附带了一个描述 XML 词汇的内置语法，称为文档类型定义 (DTD)。DTD 实际顾及到 XML 1.0是从前任语言 — 标准通用标记语言 (SGML) 那里继承语法的已经有一段时间了。 DTD 使您能够描述 XML 文档的结构。例如，假定要使用以下 XML 词汇描述员工信息： employee id=555-12-3434 nameMonica/name hiredate1997-12-02/hiredate salary42000.00/salary /employee 以下 DTD 描述了本文档的结构： !-- employee.dtd -- !ELEMENT employee (name, hiredate, salary) !ATTLIST employee id CDATA #REQUIRED !ELEMENT name (#PCDATA) !ELEMENT hiredate (#PCDATA) !ELEMENT salary (#PCDATA) 然后，该 DTD 能够通过一个 DOCTYPE 声明和原始文档相关联，如下所示： !DOCTYPE employee SYSTEM employee.dtd employee id=555-12-3434 nameMonica/name hiredate1997-12-02/hiredate salary42000.00/salary /employee 验证是使用 DTD 的主要优势。当 XML 1.0 验证分析器读取该 XML 1.0 文件时，它也能够读取相关联的 DTD 并验证是否符合该定义。使用 DTD 进行验证能够减少您必须置入应用程序的错误处理量。 尽管 DTD 非常适合很多基于 SGML 的电子出版应用程序，但当应用到诸如那些围绕当今 Web 应用的现代软件开发领域时，其局限性很快就显现出来了。DTD 的主要限制是 DTD 语法和 XML 不兼容，而且 DTD 不支持命名空间、典型编程语言数据类型或定义自定义类型。 由于 DTD 语法本身不是 XML，所以不能使用标准的 XML 工具来程序化地处理这些定义。大多数 XML 1.0 处理器虽然支持 DTD 验证，但由于语法的复杂性，它不支持对 DTD中找到的信息进行程序化访问。 因为 DTD 甚至在命名空间存在以前就产生了，所以它们不能很好地协同工作就不奇怪了。事实上，使用 DTD 描述可识别命名空间的文档就像将一个方形木栓敲进一个圆孔一样。有关如何才能艰难地实现上述功能的详细信息，请查看 2001 年 5 月期的 XML 文件专栏。在该专栏中，我提供了一个可识别命名空间的示例 DTD。因此，大多数开发人员要么选用DTD，要么选用命名空间，但没有两个同时选用的。 DTD 也是专门为以文挡为中心的系统而设计的，在这 种系统中通常不存在程序化数据类型。因此，只存在少数类型标识符用于描述属性（参见 图 1）。这些类型标识符和您过去在编程语言里惯于使用的大不相同。它们实际上仅仅是文本的特例 (CDATA)。而且，这些类型不能应用于纯文本元素，只能应用于属性。 最后，DTD 类型系统是不可扩展的。这意味着您不得不使用 图 1中描述的类型。创建在您的问题领域中有意义的自定 义类型不属于 DTD 问题的范畴。在面对 XML 架构展现的全新而又令人振奋的未来时，这些局限足以让任何 XML 开发人员回避使用 DTD。 XML 架构基础知识 XML 架构本身是一个用于描述 XML 实例文档的 XML 词汇。我之所以使用“实例”一词，是因为一个架构会描述一类文档，这类文档会有许多不同的实例（参见图 2）。这类似于现在面向对象系统中类和对象之间的关系。类相对于架构，对象相对于 XML 文档。因此，在使用 XML 架构时，您通常要使用不止一个文档，还有架构以及一个或多个 XML 实例文档。 图 2 命名空间标识符链接 架构定义中使用的元素来自 /2001/XMLSchema 命名空间，在本专栏的以下部分，我会将其绑定到 xsd。以下为基本的架构模板： xsd:schema xmlns:xsd=/2001/XMLSchema targetNamespace