xml-了解 XML 架构

了解 XML 架构
发布日期： 4/13/2004 | 更新日期： 4/13/2004
Aaron Skonnard
DevelopMentor
2003 年 3 月
适用于：
类型系统
XML 架构定义语言 (XSD)
Web 服务开发

本页内容
简介
数据类型：值和词法空间
在命名空间中定义类型
定义简单类型
定义复杂类型
定位和管理架构
小结
参考
摘要：XML 架构预计将在未来的 XML 处理中扮演核心角色，尤其是在 Web 服务领域，它将作为构建更高级别抽象的重要基础之一。本文详细地说明了如何使用 XML 架构定义语言。（22 页打印页）
简介
1 + 2 = ?
在软件中，回答此类问题所需的信息是由类型系统来提供的。编程语言使用类型系统来简化生成优质代码的任务。类型系统定义了一组可供开发人员在其程序设计中选择使用的类型和操作。一个类型定义一个值空间，或者换句话说，定义一组可能的值。例如，如果上面的操作数被认为是数值类型，答案就可能是 3；但如果它们被认为是字符串型，答案就可能是 “12”，具体情况取决于 “+” 运算符是如何定义的。
类型系统的主要好处之一是，编译器可以使用它在运行前确定代码中是否包含错误，这样就避免了可能产生大量的错误。编译器还可以利用类型系统信息针对给定类型生成操作代码。另外，编译器和运行库都在很大程度上依赖类型系统来确定在使用某个特定类型时如何分配内存空间，这使得开发人员可以不关注这些单调乏味的工作。
许多语言和运行库还允许在运行时以编程方式检查类型信息。这就使开发人员能够考虑得多一点，提出关于类型特征的问题，并且做出基于相应答案的决定。这种在运行时检查类型信息的技术通常被称为反射。在今天的主流编程环境（例如，Microsoft? .NET 框架和 Java）中，反射扮演了重要角色，这有效地减少了开发人员在其代码中必须考虑的问题。在这些编程环境中，虚拟机（例如，公共语言运行库或 JVM）提供大多数程序所需的额外服务（例如，安全、垃圾回收、序列化、远程方法调用甚至是 Web 服务集成）。

图 1. 类型信息的好处
一个定义完善的类型系统以及反射还能够创建更好的工具，以便与这种语言共同使用。开发人员已经能够快速适应许多事情，例如，Microsoft? Intellisense?、代码完成以及那些能够大大加速开发过程的方便的红色 Squiggle。大体说来，一个好的类型系统会提供许多有趣的好处（请参见图 1），其中的大部分好处是容易被当作理所当然、而没有时却让人倍感失落的那种。
XML 1.0 是一个缺乏智能类型系统的语言的典型示例。如果没有类型系统，则在 XML 1.0 文档中找到的信息只能被视为文本。这就要求开发人员事先知道“真正的类型”，以便他们在代码中执行必要的强制。
XML 架构定义语言 (XSD) 为 XML 处理环境提供了一种类型系统。在小容器中，XML 架构可以描述您要使用的类型。符合 XML 架构类型的 XML 文档通常是指实例 文档，这与类和对象间传统的面向对象的 (OO) 关系非常相似（请参见图 2）。这是一种跳离文档类型定义 (DTD) 的基本工作方式的概念切换，它可在映射到传统的编程语言或数据库类型系统时提供更大的灵活性。在这些环境中，XML 架构大大否决了 DTD 的使用。

图 2. OO 与 XML 概念
XML 架构只有在一种完全以 XML 为中心的方式下，才能够提供图 1 所示的全部好处。包含 XML 架构类型信息的逻辑 XML 文档通常被称为后架构验证信息集 (PSVI)。PSVI 使得如下操作成为可能：像在其他编程环境中一样，在运行时执行基于 XML 架构的反射。总的说来，XML 架构预计将在未来的 XML 处理中扮演核心角色，尤其是在 Web 服务领域，它将作为构建更高级别抽象的重要基础之一。本文的剩余部分将更详细地介绍如何使用 XML 架构定义语言。
返回页首
数据类型：值和词法空间
XML 架构提供一个内置数据类型 清单，开发人员可以使用它来约束文本（有关帮助图，请参见W3C XML Schema Part 2:Datatypes Web page）。所有这些类型都可以在http://www.w3.org/2001/XMLSchema 命名空间中找到。每种类型都有一个定义好的值空间。类型的值空间仅仅是可用在给定类型的实例中的一组值。

图 3. 字节值空间
例如，XML 架构提供了一种名为字节的内置类型，它具有从 -128 到 127 的值空间。另一个示例是 XML 架构中的布尔类型，它的值空间非常简单，因为它只有以下两个值：真 和假。共有 44 种内置类型供您选择，每种都有不同的值空间以满足不同数据建模的需要。
图 4 阐释了许多内置类型都被定义为另外一种类型的值空间的子集，也称为通过限制派生。例如，字节型值空间是短整型值空间的子集，短整型值空间又是整型值空间的子集，而整型值空间又是长整型值空间的子集，等等。因此，基本集合论告诉我们，一种派生类型的实例也是它的任一祖先类型的有效实例。（严格地说，它们是 anySimpleType 本身的子集。）
尽管编程语言使用值空间信息来计算需要多大的内存来表示值，开发人员却极少需要担心将它们表示为文本的问题。然而，对于 XML，却不能忽视一个事实，那就是实例将很可能序列化为 XML 1.0 文件，这需要以词法形式表示值。如果每个 XML 架构处理器都独立地决定如何进行此操作，那么互操作性很快就会失去。因此，除了定义每种类型的值空间外，XML 架构还定义了它们所允许的词法表示形式。

图 4. 类型子集
例如，布尔型的真值可以表示为 “true” 或 “1”，而布尔型的假值可以表示为 “false” 或 “0”。双精度型值 10 可以表示为 “10”、“10.0” 或 “10.0000”，甚至可表示为 “0.01E3”。而日期型的“2003 年 1 月 1 日”就可以用词法格式表示为“2003-01-01”。如果使任何类型的词法格式（以及任何可能的变化形式）都符合标准，开发人员就可以不考虑代码实际序列化方式的复杂性，而专门处理代码中的值。
返回页首
在命名空间中定义类型
除了提供内置类型外，大部分编程语言还允许开发人员定义他们自己的类型，它们通常被称为用户定义类型 (UDT)。在定义 UDT 时，大部分编程语言还允许您用命名空间来限定它们，以便使它们不会与其他恰好与其具有相同名称的 UDT 相混淆。有关 XML 命名空间如何工作的详细信息，请参阅了解 XML 命名空间。图 5 显示了一个 C# 命名空间定义和一个与之类似的 XML 架构定义。正如您所看到的一样，XML 架构还支持在命名空间内定义类型。

图 5. 在命名空间中定义类型
xsd:schema 元素确定命名空间中的内容范围，而targetNamespace 属性指定命名空间的名称。例如，下面的 XML 架构模板定义一个新的名为 http://example.org/publishing 的命名空间：
.........
位于 xsd:schema 元素内的所有内容（作为直接子级）都被认为是全局的，因此它们会自动与目标命名空间相关联。在上例中，http://example.org/publishing 命名空间中共有 4 个元素：AuthorId、AuthorType、author 和 authorId。因此，无论何时在架构内引用其中的一个元素，都必须使用命名空间限定的名称。
为了使用命名空间限定的名称，还将需要另外一个命名空间声明，该声明映射到架构的 targetNamespace 值。上面显示的 “tns” 命名空间声明的作用就在于此。因此，我无论何时需要引用我在架构中定义的内容，都可以在名称前加上 “tns” 前缀，如本例所示。
您可以在 xsd:schema 元素内定义两种类型：简单类型（使用 xsd:simpleType）和复杂类型（使用 xsd:complexType）。简单类型只能分配给纯文本元素和属性，因为它们并不定义结构，而是定义值空间。具有附加结构的元素（例如，带有属性或子元素的元素）必须定义为复杂类型。
除了定义类型，您还可以在架构内定义全局元素（使用 xsd:element）和属性（使用 xsd:attribute），并为它们指定类型。在上例中，我定义了一个名为 author 的全局元素和一个名为 authorId 的全局属性。因为这些构造也是全局的，所以当我在实例文档中使用它们时，必须通过目标命名空间对其进行限定。下面的 XML 文档包含前面定义的 author 元素的一个实例：
...
下面的 XML 文档包含全局 authorId 属性：

也可以使用 http://www.w3.org/2001/XMLSchema-instance 命名空间中的 type 属性为实例文档中的元素显式指定类型。这个命名空间包含少数只能用在实例文档中的属性。使用类型属性类似于在一些编程语言中的类型间进行强制转换。下例为 genericId 元素（尚未在架构中定义）显式指定 AuthorId 类型：
333-33-3333
请注意，AuthorId 和我们指定给上面显示的全局 authorId 属性的类型是相同的。这表明您能够为属性或纯文本元素指定简单类型以约束它们的值。同样，一定要注意到，用于指定类型的 xsi:type 技术只能应用于元素，而不能应用于属性。
返回页首
定义简单类型
大多数编程语言只允许开发人员将多种内置类型排列为某种结构化类型，而不允许开发人员定义新的具有用户定义的值空间的简单类型。在这一点上，XML 架构有所不同，因为它允许用户定义其各自的自定义简单类型，这些简单类型的值空间是预定义的内置类型的子集。
像前面显示的那样，您可以使用 xsd:simpleType 元素定义新的简单类型。在 xsd:simpleType 元素内，可以指定一个您希望限制（使用 xsd:restriction 元素）其值空间的基类型。在 xsd:restriction 元素内，您可以通过限制一个或多个方面 来准确指定希望如何来限制基类型。例如，下面的简单类型使用 xsd:minInclusive 和 xsd:maxInclusive 方面约束 xsd:double 和 xsd:date 值空间：
......
下面的文档包含上面定义的元素的有效实例：
17.5 2003-06-01
XML 架构定义了可用于每种类型的方面（请参阅表 1）。大多数方面都不能应用于所有类型（一些方面仅对某些类型有意义）。大多数方面限制了类型的值空间，而模式方面则限制了类型的词法空间。对于值空间和词法空间来说，限制两者中的任一者都会间接地限制另外一个。先前的示例约束了基类型的值空间，而接下来的示例使用正则表达约束了字符串的词法空间：
......
下面的文档包含上面定义的元素的有效实例：
123-45-678901-23456789(801)390-4552
只有与正则表达式（在模式方面中指定）相匹配的字符串才被认为是给定类型的有效实例。
方面元素 说明
xsd:enumeration
指定一个该类型必须匹配的固定值。
xsd:fractionDigits
指定小数点右侧十进制位数的最大值。
xsd:length
指定基于字符串的类型中的字符数量、基于二进制的类型中的八位字节数量或者基于列表的类型中的项数量。
xsd:maxExclusive
指定该类型的值空间的上限（不包括上限）。
xsd:maxInclusive
指定该类型的值空间的上限（包括上限）。
xsd:maxLength
指定基于字符串的类型中字符的最大量、基于二进制的类型中的八位字节的最大数量或者基于列表的类型中项的最大数量。
xsd:minExclusive
指定该类型的值空间的下限（不包括下限）。
xsd:minInclusive
指定该类型的值空间的下限（包括下限）。
xsd:minLength
指定基于字符串的类型中字符的最小数量、基于二进制的类型中的八位字节的最小数量或者基于列表的类型中项的最小数量。
xsd:pattern
基于正则表达式指定一个该类型必须匹配的模式。
xsd:totalDigits
为从数字派生的类型指定十进制数的最大值。
xsd:whiteSpace
指定空白正常化规则。
表 1. 方面
另一个有趣的方面是 xsd:enumeration，它允许将值空间约束为枚举值列表。下面的示例将 xsd:NMTOKEN 的值空间约束为四个特定的枚举值：
......
下面的文档包含上面定义的元素的有效实例：
Online 派生元素 说明
xsd:restriction
新类型是现有类型的限制，这表示新类型具有一组范围更窄的合法值。
xsd:list
新类型是另一个简单类型的、用空白分隔的列表。
xsd:union
新类型是两个或更多其他简单类型的联合。
表 2. 简单类型的构造技巧
除了限制类型的值空间外，还可以构造新的作为其他简单类型的列表 或联合 的简单类型。为此，要使用 xsd:list 或 xsd:union 元素，而不使用 xsd:restriction（请参阅表 2）。在使用 xsd:list 时，实质上是在从指定的值空间定义一个用空白分隔的值列表。值得提醒的是，在使用 xsd:list 或 xsd:union 时，不像使用 xsd:restriction 时那样具有派生层次结构，因此在这些情况下不能应用类型兼容性。下例将名为 AuthorList 的新类型定义为 SSN 值列表。
......
下面的文档包含 authors 元素的有效实例：
111-11-1111 222-22-2222 333-33-3333 444-44-4444
对于 xsd:union 来说，是在创建一种可将多个值空间组合到一个新的值空间中的新类型。联合类型的实例可以是所指定的任何值空间中的值。例如，下面的名为 AuthorId 的类型将 SSN 值空间与 PublisherAssignedId 值空间组合在一起：
......
下面的每个文档都显示 authorId 元素的一个有效实例：
111-11-111122-22222222
XML 架构对用户定义类型（以及更具体的自定义值空间/词法空间）的支持是这种语言更强大的方面之一。由于大多数编程语言不提供该支持，因此开发人员不得不在他们的应用程序代码中处理此类问题（通常是通过属性的 setter）。这种可定义能够完全满足您的需求的自定义值空间/词法空间的功能使错误处理和验证代码问题降低一个难度级别。
......返回页首
定义复杂类型
XML 架构允许将不同的简单类型（或值空间）排列为结构（也称作复杂类型）。可以使用 xsd:complexType 元素在架构的目标命名空间内定义新的复杂类型，如下所示：
xsd:complexType 元素包含所谓的合成器，合成器描述类型内容的合成，因此又被称作该元素的内容模型。XML 架构定义了三个可用在复杂类型定义中的合成器：xsd:sequence、xsd:choice 和 xsd:all（请参阅表 3）。
合成器中包含粒子，而粒子中包括诸如其他合成器、元素声明、通配符和模型组之类的内容。属性声明并不被视为粒子，因为它们不重复。因此，属性声明不会放在合成器内，而是放在复杂类型定义结尾处的合成器后面。
合成器 定义
xsd:sequence
所包含粒子的有序序列。
xsd:choice
可供选择的所包含粒子。
xsd:all
以任何顺序排列的所有所包含粒子。
表 3. 复杂类型合成器
元素声明 (xsd:element) 可能是最常用的粒子。下面的名为 AuthorType 的 complexType 定义了一个由两个子元素和一个属性（此处的子元素和属性分属于不同的简单类型）组成的有序序列：
......
在 xsd:complexType 元素内声明的元素和属性被视为该复杂类型的局部 元素和属性。局部元素和属性只能在定义它们的上下文内使用。这就引发了一个有趣的问题：在实例文档中，局部元素/属性是否需要由命名空间来限定。因为局部元素属性总是包含由目标命名空间限定的祖先元素（通常是全局元素），所以人们可以认为让局部元素和属性也由命名空间限定并不是必要的。这与大多数编程语言中的工作方式相类似 － 如果您在一个命名空间中定义了一个类，则只有该类的名称由命名空间限定，而它的局部成员则不会被限定。
由于这个原因，在 XML 架构中，局部元素和属性在默认情况下应当不受限定。因此，author 元素的有效实例如下所示：
Aaron Skonnard(801)390-4552
然而，XML 架构允许使用 xsd:element/xsd:attribute 的 form 属性或者使用 xsd:schema 的 elementFormDefault/attributeFormDefault 属性，来显示控制给定的局部元素/属性是应当受限定还是不受限定，如下所示：
...
在有了此架构之后，下面的实例将被视为有效实例（而上面的实例将被视为无效实例）：
Aaron Skonnard(801)390-4552
在大多数情况下，只要实例与架构相符合，那么对局部元素使用哪种命名空间样式就无关紧要了。
您也可以使用 ref 属性在一个复杂类型内引用全局元素/属性声明，如下所示：
......
由于 id 和 name 是全局元素，因此它们在实例文档中总是需要受到限定。使用 “ref” 可以指定全局元素同样可以用在 AuthorType μ?上下文内，但这并没有改变它需要受到限定这一事实。phone 元素仍然是在局部定义的，这意味着，在实例中，它可能需要也可能不需要受到限定，具体情况取决于所使用的形式。因此，假设 elementFormDefault="unqualified"，有效实例将如下所示：
Aaron Skonnard(801)390-4552
下面是一个稍微复杂点的示例，它使用嵌套的复杂类型、其他合成器和重复粒子：
...
在本例中，AuthorType 包含由另一个合成器和一个选项组成的序列，其后还有三个元素声明。一些元素属于其他由用户定义的复杂类型（AddressType 和 PublicationsListType），这些复杂类型可在该类型内有效地定义嵌套结构。此选项意味着是允许 name 元素还是允许 fullName 元素出现在该位置。最后，AddressType 中的 all 合成器指出元素的顺序是可以忽略的。
另请注意，phone 元素声明使用 minOccurs 和 maxOccurs 元素指定出现约束。出现约束可以应用于复杂类型中的任何粒子。每个出现约束的默认值是 1，这意味着给定的粒子必须在指定的位置出现一次。指定 minOccurs="0"