为何应该使用内置的简单类型
W3C XML 架构比 XML 1.0 中的 DTD 优越，主要表现在它的数据类型方面。在 W3C XML 架构中，可以将元素值或属性值指定为字符串、日期或数值数据，这使得架构作者能够以互操作和独立于平台的方式来指定并验证 XML 数据的内容。由于存在许多内置数据类型（约 44 种），如果架构作者对内置类型的子集进行标准化以避免信息重载，这将是十分明智的。
大多数情况下，用户不需要使用 xs:string（如 xs:ENTITY 或 xs:language）的子类型、xs:integer（如 xs:short 或 xs:unsignedByte）的子类型以及 Gregorian 日期类型（如 xs:gMonthDay 或 xs:gYearMonth）。去掉上面提到的这些类型，可以将要跟踪的类型减少到可以接受的数量。
为何应该使用复杂类型
复杂类型定义用于指定由元素和属性组成的内容模型。元素声明可以通过引用某个命名或匿名的复杂类型来指定其内容模型。对于命名的复杂类型来说，可以从定义它的架构或外部架构文档中通过名称对其进行引用，而匿名的复杂类型必须在使用该类型的元素声明中定义。此外，可以使用 W3C XML 架构继承机制对命名复杂类型的内容模型进行扩展或限制。
复杂类型与模型组定义类似，但有两个主要区别：复杂类型定义可以在其定义的内容模型中包括属性，并可以使用类型派生，而命名模型组则不能。在 Kohsuke 的文章中，他主张将匿名复杂类型、模型组定义和属性组结合起来使用，而不要使用命名复杂类型来指定元素的内容模型，试图避免处理命名复杂类型的“复杂性”。但有人提出反对意见，认为在指定元素的内容模型时，使用三种机制与使用一种机制相比实际上更容易引起混乱。因此，命名复杂类型除了允许重复使用内容模型以外，还是指定元素内容模型的最直观方法。
只有不需要从元素声明外部引用类型且不需要类型派生时，才应该使用匿名复杂类型。有一点值得注意，从匿名复杂类型不能派生出新类型。一般来说，大量使用匿名类型的架构在统一性和一致性方面很可能会出问题。
为何不应该使用表示法声明
Kohsuke 曾建议避免使用表示法声明，这是完全正确的。它们的存在仅仅是为了与 DTD 保持向后兼容，但不能与 DTD 表示法向后兼容。最好假定它们根本就不存在。
为何应该慎重使用替换组
替换组为 XML 元素提供了一种类似编程语言中的子类型多态的机制。将一个或多个元素标记为可以替代全局元素（也称为头元素），意味着替换组中的成员可以与内容模型中的头元素互换。例如，对于包含成员 USAddress 和 UKAddress 的 Address 替换组来说，可以在内容模型中使用通用元素 Address，也可以用 USAddress 或 UKAddress 来取代它。唯一的要求是替换组成员的类型必须相同，或者与头元素属于同一类型层次结构。
下面给出了一个示例架构及其验证的实例：
example.xsd:
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.com"
xmlns:ex="http://www.example.com"
elementFormDefault="qualified">
<xs:element name="book" type="xs:string" />
<xs:element name="magazine" type="xs:string" substitutionGroup="ex:book" />
<xs:element name="library">
<xs:complexType>
<xs:sequence>
<xs:element ref="ex:book" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
example.xml:
<library xmlns="http://www.example.com">
<magazine>MSDN Magazine</magazine>
<book>专业的 XML 数据库</book>
</library>
在上面的例子中，library 元素的内容模型允许包含一个或多个 book 元素。由于 magazine 元素包含在 book 替换组中，因此 magazine 元素可以出现在需要 book 元素的实例 XML 中。
替换组使得内容模型更加灵活，其可扩展性大大超出架构作者的想象。灵活性是一把双刃剑，虽然它提供了更好的可扩展性，但是处理基于这种架构的文档将更加困难。例如，在上面的示例中，处理 library 元素的代码不仅要处理它的 book 子元素，还要处理 magazine 元素。如果实例文档还通过 xsi:schemaLocation 属性指定了更多架构，那么应用程序就必须将更多的 book 替换组成员作为 library 元素的子元素进行处理。
更复杂的是，替换组中的成员可以是从替换组的头类型派生出来的类型。通过编写代码来正确处理派生类型，这通常都会比较困难，尤其是当存在两种相对的派生方法时：restriction，限制内容模型的范围或值；extension，向内容模型添加元素或属性。通过使用元素声明中的某些属性，架构作者可以更好地控制实例文档中的元素替换，并降低 XML 实例文档中出现意外替换的可能性。block 属性可用于指定元素（其类型使用某种派生方法）是否可以替换实例文档中的元素，而 final 属性可用于指定元素（其类型使用某种派生方法）是否可以将自己声明为目标元素替换组的一部分。架构中所有元素声明的 block 和 final 属性的默认值都可以通过根 xs:schema 元素的 blockDefault 和 finalDefault 属性来指定。默认情况下，允许执行所有替换，没有任何限制。
为何应该使用 key/keyref/unique 而不是使用 ID/IDREF 进行标识约束
DTD 提供了一种将某种属性指定为类型 ID（即属性值在文档中是唯一的）的机制，这种机制与 XML 1.0 中的名称生成机制相对应。XML 1.0 中的 ID 也可以被类型 IDREF 或 IDREFS 的属性引用。为了与 DTD 兼容，W3C XML 架构提供了 xs:ID、xs:IDREF 和 xs:IDREFS 类型。
W3C XML 架构标识约束可用于通过使用在元素声明范围内定义的 XPath 表达式来指定唯一值、主键以及对主键的引用。从功能方面来看，标识约束机制比 ID/IDREF 机制的功能多。首先，它对可以作为标识约束使用的值或类型没有限制，而 ID 只能是规定的值之一（例如，7 就不是有效的 ID）。架构标识约束优于 ID/IDREF 的另一个重要方面在于：在文档中，后者必须是唯一的，而前者没有此项限制。换句话说，唯一 ID 的符号空间是整个文档，而唯一主键的符号空间是 Xpath 的目标范围。如果同一 XML 文档的两个不同范围有重叠的值空间，并且这些值又要求唯一，主键的这种特性就会非常有用。包含某个酒店的房间号和餐桌号的 XML 文档就是一个例子。很有可能存在号码重叠的情况（例如 18 号房间和 18 号餐桌），但是它们在自己的值空间中不应该重叠。
注意：W3C XML 架构的 ID 类型系列不完全与 DTD ID 类型兼容。首先，xs:ID、xs:IDREF 和 xs:IDREFS 类型在 W3C XML 架构中既可用于元素，也可用于属性，但在 DTD 中却只能用于属性。其次，元素中可以出现的类型 xs:ID 的属性数量没有限制，而 DTD 中的 ID 属性则有限制。
为何应该慎重使用可变架构
架构文档的目标命名空间用于标识可与架构进行验证的元素和属性的命名空间名称。没有目标命名空间的架构通常只能验证无命名空间名称的元素和属性。但是，如果一个没有目标命名空间的架构包含在另一个有目标命名空间的架构中，那么无目标命名空间的架构就把包含它的架构的目标命名空间作为自己的目标命名空间。这种功能通常称为可变架构设计模式。
在 Kohsuke 的文章中，他声称可变架构方案行不通，这种说法是不正确的。Michael Leditschke 在关于 XML-DEV 的文章中反驳了 Kohsuke 的观点，说明这种设计方案是可行的，并指出它对创建需要重复使用的类型定义和声明模块是非常有用的。
将可变架构与标识约束结合使用时会有一些问题。问题在于，在可变架构中，QName 对类型定义和声明的引用被强制应用包含架构的命名空间，但 xs:key、xs:keyref 和 xs:unique 标识约束所使用的 XPath 表达式却没有被强制应用包含架构的命名空间。请考虑以下架构：
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element name="person" type="PersonType" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:key name="PersonKey">
<xs:selector xpath="person"/>
<xs:field xpath="@name"/>
</xs:key>
<xs:keyref name="BestFriendKey" refer="PersonKey">
<xs:selector xpath="person"/>
<xs:field xpath="@best-friend"/>
</xs:keyref>
</xs:element>
<xs:complexType name="PersonType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="best-friend" type="xs:string" />
<xs:attribute name="name" type="xs:string" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
如果上面的架构被包含到另一个具有目标命名空间的架构中，那么 key 和 keyref 中的 XPath 表达式都会失败。在这个示例中，person 元素在可变架构中不具有命名空间，但是一旦被其他架构包含，它就会使用包含它的架构的目标命名空间。与没有命名空间的 person 相匹配的 XPath 表达式不能正常工作并不表示它们永远不能正常工作，因为处理器无需保证标识约束中的 path 表达式一定要返回结果。
因此，建议在可变架构中不要使用标识约束。
为何不应该使用默认值或固定值，尤其是对于 xs:Qname 类型
使用默认值和固定值的主要问题是：它们会导致在验证后将新数据插入到源 XML 中，从而改变数据。这意味着，如果某个文档中的架构使用了未经验证的默认值，该文档就是不完整的。尝试对 XML 文档的实际内容进行验证是不明智的，因为有时可能没有架构。假设文档的用户始终执行验证也是不明智的。
由于窗体不规范而需要验证时，xs:QName 类型还会出现一些其他问题。考虑以下架构和 XML 实例：
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.com"
xmlns:ex="http://www.example.com"
xmlns:ex2="ftp://ftp.example.com"
elementFormDefault="qualified">
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element name="Node" type="xs:QName" default="ex2:FtpSite" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<Root xmlns="http://www.example.com"
xmlns:ex2="smtp://smtp.example.org"
xmlns:foo="ftp://ftp.example.com">
<Node />
</Root>
在上面的例子中，应当将什么值插入到 Node 元素中以便进行验证？如果 ex2 前缀被映射到实例文档而不是架构中的不同命名空间，那么应该是 ex2:FtpSite 吗？如果“foo”前缀与 ex2 被映射到架构中相同的命名空间，那么应该是“foo:FtpSite”吗？那么，如果 ftp://ftp.example.com 命名空间没有相应的 XML 命名空间声明，将会发生什么？必须向 XML 中插入命名空间声明吗？如果不违反有关正确操作的某些观点，这些问题都得不到满意的回答。最好避免使用 xs:QName 默认值，因为在上面的例子中，不同的实现在语义上不太可能一致。
为何应该使用简单类型的限制和扩展
如前所述，W3C XML 架构中存在两种形式的类型派生：限制和扩展。对简单类型进行限制包括约束类型的各个方面，从而减少类型的允许值。这种限制包括指定字符串值的最大长度、指定日期范围或枚举允许值的列表。架构作者通常以这种方式来使用类型约束，这些类型在 W3C XML 架构中占了类型派生的绝大多数。元素和属性的类型定义中都可以使用这些类型。
对简单类型进行扩展允许您使用具有属性的简单内容来创建复杂类型（即元素内容模型）。典型的扩展例子是元素声明将简单类型作为自己的内容，并且具有一种或多种属性。由于 XML 文档中普遍存在这种元素内容模型，因此通过扩展进行派生也是架构作者常用的功能。
值得注意的是，与复杂类型一样，简单类型也有命名和匿名两种。对于命名的简单类型来说，可以从定义它的架构或外部架构文档中通过名称对其进行引用，而匿名的简单类型必须在使用该类型的元素声明或属性声明中定义。同样，与复杂类型一样，只有命名类型才能执行类型派生。
常见的错误概念是，结构相同的匿名类型就是相同的类型：
<-- 片断 A -->
<xs:element name="quantity">
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:maxExclusive value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="size">
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:maxExclusive value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
相当于：
<-- 片断 B -->
<xs:simpleType name="underHundred">
<xs:restriction base="xs:positiveInteger">
<xs:maxExclusive value="100"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="size" type="underHundred"/>
<xs:element name="quantity" type="underHundred"/>
从根本上说，认为片段 B 中的两个元素声明类型相同是错误的。即使两种类型具有相同的结构，也不能认为它们相同，除非它们已命名，名称相同，并且来自于相同的目标命名空间。W3C XML 架构的各个方面（例如替换组、指定 key/keyref 对以及类型派生）都可能要求元素声明具有相同的类型。例如，keyref 必须与 key 的类型相同。但是，W3C XML 架构的大多数功能要求片段 A 中的元素声明具有不同的类型，而片段 B 中的元素声明具有相同的类型。
为何应该使用复杂类型的扩展
对复杂类型进行扩展包括向派生类型的内容模型添加更多的属性或元素。通过扩展添加的元素按顺序附加到基本类型的内容模型中。对于提取一组复杂类型的共有特征，然后通过扩展基本类型定义来重复使用这些特征，该技术非常有用。以下架构片段来自 W3C XML Schema Primer 中的对复杂类型扩展的讨论和示例，显示了如何通过扩展来重复使用邮件地址的通用功能。
<xs:complexType name="Address">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="street" type="xs:string"/>
<xs:element name="city" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="USAddress">
<xs:complexContent>
<xs:extension base="Address">
<xs:sequence>
<xs:element name="state" type="USState"/>
<xs:element name="zip" type="xs:positiveInteger"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="UKAddress">
<xs:complexContent>
<xs:extension base="Address">
<xs:sequence>
<xs:element name="postcode" type="UKPostcode"/>
</xs:sequence>
<xs:attribute name="exportCode" type="xs:positiveInteger" fixed="1"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
在上面的架构中，Address 类型定义了一般地址共有的信息，而它的两个派生类型分别添加了美国和英国的特殊地址信息。通过扩展来重复使用和建立内容模型是 W3C XML 架构具有的一项强大且有用的功能，它促进了相似内容的模块化和一致性。
使用处理器来处理通过扩展而派生出的类型时需要注意一个问题。此问题与类型相关处理器以及通过扩展而添加到内容模型中的元素有关。将来，类型相关语言（例如 XQuery/ 或 XLST 2.0）有可能能够以多种形式来处理 XML 元素和属性。例如，应用程序可以决定处理类型 Address 的所有元素或处理以 Address 为基本类型的所有元素，选择处理所有类型的共有信息。但是，对于下面的查询：
//*[. instance of Address]/city
如果使用以下方法处理扩展了内容模型的派生类型，它将返回意外的结果：
<xs:complexType name="BadAddress">
<xs:complexContent>
<xs:extension base="Address">
<xs:sequence>
<-- 地址格式中有两个 city 项，一个用于临近地区，
另一个用于实际的城市 -->
<xs:element name="city" type="xs:string"/>
<xs:element name="state" type="xs:string"/>
<xs:element name="country" type="xs:string"/>
</xs:sequence>
<xs:attribute name="exportCode" type="positiveInteger" fixed="1"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
尽管上面的例子是专门设计的且似乎是不可能的，但它说明了确实存在危险。有关这个潜在问题的详细说明，请参阅 Paul Prescod on XML-Dev。
为何应该慎重使用复杂类型的限制
对复杂类型的限制包括创建派生的复杂类型（其内容模型是基本类型的子集）。
首先，给您一些忠告。W3C XML 架构建议中描述的通过限制复杂类型来进行派生（第 3.4.6 节和第 3.9.6 节）通常被认为是文档最复杂的部分，一般较难理解。实现时的大部分问题出在如何正确支持此功能方面，因此，当讨论通过限制复杂类型来进行派生的各种细节时，经常可以看到实现者们争论得面红耳赤。另一个问题是，通过限制复杂类型而实现的派生不能很好地映射到面向对象编程或关系数据库理论中的概念，而面向对象编程和关系数据库理论却是 XML 数据的主要来源和使用者。这与通过扩展复杂类型来进行派生的情形完全相反。
通过限制复杂类型来进行派生的另一问题是由声明限制的方法导致的：如果某个给定的复杂类型是通过限制另一个复杂类型而派生得到的，则必须复制和重定义它的内容模型。定义的副本会复制定义，这可能要经过一个很长的派生链，因此，对初始类型进行任何修改都必须手动传遍派生树。而且，这种复制不能越过命名空间边界 - 如果 ns2:SlowCar 具有子元素 ns2:MaxSpeed，则可能无法从 ns1:Car 派生 ns2:SlowCar，因为无法正确从 ns1:Car 的子元素 ns1:MaxSpeed 派生出 ns2:MaxSpeed。
以下架构通过限制派生方式来限制一个复杂类型，该复杂类型将 XML-DEV 邮件列表的一个用户描述为说明 Dare Obasanjo 的类型。符合 DareObasanjo 类型的任何元素也可以作为 XML-Deviant 类型的实例进行验证。
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema>
<!-- 基本类型 -->
<xs:complexType name="XML-Deviant">
<xs:sequence>
<xs:element name="numPosts" type="xs:integer" minOccurs="0"
maxOccurs="1" />
<xs:element name="signature" type="xs:string" nillable="true" />
</xs:sequence>
<xs:attribute name="firstSubscribed" type="xs:date" use="optional" />
<xs:attribute name="mailReader" type="xs:string"/>
</xs:complexType>
<!-- 派生类型 -->
<xs:complexType name="DareObasanjo">
<xs:complexContent>
<xs:restriction base="XML-Deviant">
<xs:sequence>
<xs:element name="numPosts" type="xs:integer" minOccurs="1" />
<xs:element name="signature" type="xs:string" nillable="false" />
</xs:sequence>
<xs:attribute name="firstSubscribed" type="xs:date" use="required" />
<xs:attribute name="mailReader" type="xs:string" fixed="Microsoft Outlook" />
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
通过限制复杂类型而进行的派生是一种具有多面性的功能，当第二种类型需要符合通用的主类型时它非常有用，但却为自己添加了比主类型更多的约束。但是，因为它太复杂，所以只有完全了解 W3C XML 架构功能的人才可以使用。
为何应该慎重使用抽象类型
通过借用面向对象编程语言如 C# 和 Java 中的一个概念，元素声明和复杂类型定义都可以变成抽象的。抽象元素声明指的是元素声明不能用于验证 XML 实例文档中的元素，只能通过替换出现在内容模型中。与此类似，抽象复杂类型定义也不能用于验证 XML 实例文档中的元素，但是可以用作元素派生类型的抽象父元素，或在使用 xsi:type 替代实例中的元素类型时使用。
抽象复杂类型和元素声明对于创建包含一组类型（例如 Shape 与 Circle 或 Square）的常见信息的通用基本类型很有用。但是只有在应用了其他派生（扩展或限制）后，定义才是“完整的”。尽管此功能易于使用，但其使用存在一些微妙和复杂之处，因此，使用抽象类型时应慎重。
应该使用通配符以提高可扩展性
W3C XML 架构提供了通配符 xs:any 和 xs:anyAttribute，用来使指定命名空间中的元素和属性出现在内容模型中。使用通配符，架构作者既能使内容模型可扩展，同时又能保持对元素和属性的控制。有关使用通配符的好处，请参阅 W3C XML 架构设计模式：处理改变中的讨论。
谨慎的架构作者关心由类型派生引起的问题，可能在复杂类型定义和元素声明中使用 final 属性（与 C# 中的 sealed 和 Java 中的 final 一样）来禁止类型派生，然后使用通配符对内容模型的某些部分实现扩展。这样，架构作者就可以更好地控制他们所定义的内容模型，从而减少复杂类型派生所出现的各种问题（尤其是通过扩展进行派生所引起的问题）。
值得注意的是，通配符有时会出现不确定性问题，如果使用不当，会与 Unique Particle Attribution 规则冲突。以下架构就出现了这样的问题，原因是：
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.com/fruit/"
elementFormDefault="qualified">
<xs:complexType name="myKitchen">
<xs:choice maxOccurs="unbounded">
<xs:any processContents="skip" />
<xs:element name="apple" type="xs:string"/>
<xs:element name="cherry" type="xs:string"/>
</xs:choice>
</xs:complexType>
</xs:schema>
...myKitchen 类型的内容模型可以包括一个或多个 apple、cherry 或任意其他元素。但是，在验证过程中，如果遇到一个 <apple> 元素，编译器不能辨别是根据通配符进行验证，还是根据苹果元素声明进行验证，于是导致不明确。
选择 namepsace 属性和 processContents 属性有一些既微妙又深奥的细节。过度限制值可能会妨碍可扩展性，而过度开放值又可能导致架构的误用。控制通配符支持的命名空间也容易使人不知所措，尤其是当可选命名空间集可能会发生改变时。
不要使用组或类型重定义
重定义是 W3C XML 架构的一种功能，它允许您改变已包含的类型或组定义的含义。架构作者可以使用 xs:redefine，包括架构文档中的类型或组定义，然后以某种方式改变这些定义。重定义会同时影响具有包含关系的两个架构中的类型或组定义，所以其影响相当广泛。这样，所有对两个架构中原始类型或组的引用都将引用重定义的类型，同时原始定义被屏蔽。这样就导致了 W3C XML 架构设计模式：处理改变中指出的问题：
这将在一定程度上削弱性能，因为重定义的类型可以逆向与派生类型结合，产生冲突。常见的冲突是当派生类型使用扩展向类型的内容模型添加元素或属性时，重定义也向内容模型添加类似的命名元素或属性。
类型重定义的主要问题是，与类型派生不同，不能使用 block 或 final 属性来禁止类型重定义。因此，所有架构均可以通过一般方法重定义自身的类型，从而完全改变它们的语义。由于可能会引起冲突，建议避免使用此功能。
许多架构作者试图使用类型重定义来加大枚举类型的值空间，但这种方式不能获得成功。用作基本类型的枚举类型可以接受的、唯一可以增加值的数量的方法是创建一个 union。但是，添加的这些值只能用于产生 union 类型的应用程序，而不能用于原始基本类型的应用程序。此外，还需要注意的是链式重定义（对重定义的类型再次重定义）可能会出现问题，导致意外的定义冲突。
[返回] W3CHINA.ORG讨论区 - 语义网·描述逻辑·本体·RDF·OWL →
XML.ORG.CN讨论区 - 高级XML应用 → 『 XML 与 数据库 』 → W3C XML 架构设计模式：避免复杂性2[分享]
(订阅本版)
2005/9/23 17:31:00
新浪微博
W3C XML 架构设计模式：避免复杂性2[分享]
