W3C XML架构设计指南：实用原则与避免复杂性

41 浏览量更新于2024-07-15 收藏 270KB PDF 举报

W3C XML架构设计模式：避免复杂性是一篇深入探讨如何有效利用W3C XML架构语言以减少设计复杂性的文章。作者Kohsuke Kawaguchi在其初始的指导方针中强调了几个关键原则，本文对其进行了详尽的评论和扩展建议。以下是一些核心知识点： 1. 全局和局部元素声明：应区分全局元素（在整个文档中定义）和局部元素（仅在特定上下文中定义），这有助于维护清晰的结构和避免命名冲突。 2. 全局和局部属性声明：同样的，全局属性应只在顶级元素中定义，局部属性用于特定元素，以保持灵活性和一致性。 3. XML命名空间：理解命名空间的重要性，因为它能帮助管理元素和属性的唯一标识，防止不同来源的数据混淆。 4. `elementFormDefault` 设置：始终将其设置为“qualified”，确保元素和属性名称的完整限定，提高数据的可移植性和互操作性。 5. 使用属性组和模型组：简化文档，通过组合相关属性或元素创建模块化的定义，提高代码复用和易读性。 6. 内置简单类型与复杂类型：优先使用内置简单类型（如xs:string, xs:integer等）来保持架构简洁，复杂类型（如xs:complexType）则用于更复杂的数据结构。 7. 避免使用表示法声明：除非必要，否则避免使用复杂的语法表示，因为它们可能导致解析困难和文档维护成本增加。 8. 选择正确的标识约束：推荐使用`key/keyref/unique`而非`ID/IDREF`，前者更灵活，易于维护和扩展。 9. 可变架构谨慎使用：避免过度依赖可变架构，因为它可能增加理解和维护的难度。 10. 避免默认值和固定值：特别是对`xs:QName`类型的处理，过多的预设值可能引发问题。 11. 简单类型限制和扩展：利用简单类型的优势，如限制或扩展其允许的范围，保持数据的一致性。 12. 复杂类型扩展：当确实需要时，谨慎地扩展复杂类型，确保不会引入不必要的复杂性。 13. 抽象类型使用：避免过度抽象，保持架构的实际用途。 14. 通配符的使用：为了保持架构的灵活性和适应性，可以考虑使用通配符，但需确保适度。 15. 避免组和类型重定义：重定义可能导致混乱，尽量利用现有的定义来保持一致性。 16. 总结：文章提倡以实用主义的态度对待W3C XML架构，避免不必要的复杂性，同时充分利用其强大的功能。通过遵循这些指导方针，架构设计师可以更好地设计出简洁、易于理解和维护的XML架构。

为何应该慎重使用替换组为何应该慎重使用替换组

替换组为 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:

<magazine>MSDN Magazine</magazine>

</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 类型类型

剩余32页未读，继续阅读

weixin_38704870

粉丝: 6
资源: 999

W3C XML架构设计指南：实用原则与避免复杂性

W3C XML Schema

W3C XML Schema 模式的设计方法研究.pdfW3C XML Schema 模式的设计方法研究.pdf

W3C教程(8):W3C XML Schema 活动

使用W3CXML架构处理文档结构变化与进化

W3C教程(10):W3C XQuery 活动

XML应用的基石：XML解析技术

XML架构的接口复杂性新指标：NIC度量

《O'Reilly XML_Schema权威指南》：详解复杂性的强大工具

Concentré Xml Tools：基于W3C标准的开源Xforms/Xml框架

XML Schema结构详解：定义与优势

最新资源