真实世界中的 XML Schema

国际 XML 零售合作组织（International XML Retail Cooperative (IXRetail)）是标准化 XML 消息（用于在支持零售商店的 IT 系统之间进行交换）的 ARTS 委员会。IXRetail 改编了 ARTS 数据模型（ARTS Data Model）标准中的名称和定义，使它们在 XML 消息中使用。IXRetail 还致力于使 XML 技术的其它方面在零售业及其供应商范围内标准化。

最初本文发布在 NRF 的 STORES Magazine 上，共有两部分。在参考资料一节中有那些文章部分的在线版本的链接。那些部分的材料已经为 developerWorks 的读者收集在这里并进行了修改。

XML Schema 语言
XML 为识别应用程序需要的信息提供了格式，但不能保证提供了接收方需要的信息。但是，XML 提供了帮助以获得这个保证的格式结构。XML Schema 语言详细说明了 XML 和相关规范，以便提供一种灵活的方法来描述能用来标记 XML 文档的名称的共享词汇表。通过使用共享模式，应用程序可以使用验证解析器来确保发送或接收到的是适当的信息。

IXRetail 选择了 XML，因为 XML 对 Web 上的结构化文档和数据交换有普遍的适用性。XML 和 XML Schema 语言被设计成包含几乎任何需要都适用的工具的通用解决方案。这使得 XML Schema 的使用太通用而没有附加约束。例如，有多种方法来描述一个集合中的值，这个集合可以是多种多样的：xs:choice、元素替代组、抽象元素、抽象类型以及更多。这些方案的每一个都有不同的特征。在某些情况下，一个方案可能很明显是最合适的一个。但是，在许多情况下，可能要选择几个不同的方案。这并不是我们想要的：在适合的 XML Schema 特性之间进行任意选择会隐藏相关消息内或者类似的类型之间的相似性，并且会使维护或者扩充消息系统的人们将精力浪费在保留任意选择的集合上。在许多情况下，IXRetail 采用了“最佳实践”指导原则，声明在特定情况下，优先使用 XML 或者 XML Schema 语言的特定特性。

一个模式可以提供给应用程序的保证级别取决于这个模式如何很好地将应用程序需求转换为 XML 消息需求。XML Schema 语言可以描述 XML 消息组件上的绝大部分公共约束。在某些情况下，可以用一个最理想的模式来验证每个“好的”消息并拒绝每个“坏的”消息。

但是，甚至当可能有这样一个最理想的模式时，您可能要让应用程序处理一些坏消息（诸如当在一个标准化的模式中，对于枚举有效值更改过于动态）。而且，一些约束不能用 XML Schema 语言进行描述。因此，对具有 XML 模式的消息的验证无法省去应用程序验证输入数据是否可接受的需要。

与消息的好坏取决于应用程序认为它们是否可接受一样，如果模式可以被一些准则接受，那么它们就可以被认为是好的。问题是，哪些准则呢？

有些准则看起来很明显。符合 XML Schema 语言的工具可以处理用这种语言编写的模式，这暗示了在 XML 模式中使用 W3C 规范应该是一个指导原则。但事情并不总是如此的明显，因为 W3C 正式采用 XML Schema 语言只是近期的事。许多人预言这种语言将被淘汰，因为刚出现时它很复杂，而且变得越来越糟。但是，这种复杂性是处理各种不同使用所必需的。

“好的”XML 和 XML Schema 规范的准则可能变化很大，这取决于如何使用那些规范。甚至当存在着在 XML Schema 中使用 W3C 规范的协议时，对于规范，还是可能没有“好的”应用程序标准的唯一的准则集合；决定“最好”的准则甚至可能更不确定。但是，当可以限制应用程序的特殊环境时，可以希望确定 — 通过集思广益并经一致同意 — 在那个环境中导致使用 XML 和相关标准的最佳实践的准则集合。在这种情况下，这个特殊环境是信息技术应用程序之间的数据互换，这些应用程序或者支持零售商店的运作或者将零售商店与零售企业集成。

最佳实践
IXRetail 技术委员会（IXRetail Technical Committee）批准了下面列出的最佳实践指导原则。这些指导原则按 IXRetail 的最佳实践小组委员会（Best Practices Subcommittee）批准的先后次序列出；这个顺序没有其它意义。每个指导原则以粗体显示，后跟描述该指导原则的基本原理注释或本文作者的相关备注。但是，只有指导原则获得了批准；IXRetail 没有批准注释。在使用的过程中这些指导原则可能获得发展并促进其它指导原则。ARTS 开发了这些实践来引导它的标准化的 XML 模式的开发。它发布这些实践来引导零售应用程序的开发人员，直至他们能使用即将发布的 ARTS 标准。如果开发其它种类的应用程序，那么其中许多指导原则可以提高 XML 模式的一致性（只需将 IXRetail 替代为您的规范批准者的名称）。

对指定的所有 XML 名称，使用“UCC 大小写混合（camel case）”并且在单词之间没有空格或者连字符。这种大小写混合产生的结果是复合名称的每个词的第一个字母大写，包括这个名称的首字母大写。这样确保名称对于 XML 来说是合法的（没有空格）而且比单一大小写的文本更具可读性。UCC 大小写混合的名称的示例是 InventoryControlDocument。（有些组织已经采用了使用 LCC 大小写混合的命名标准，比如在几种名称，通常是属性名称中使用 initialLowerCase。IXRetail 决定不这样做。决定是使用 UCC 还是 LCC 或者两者都使用不受 XML Schema 的驱使，XML Schema 对于元素、属性以及类型有截然不同的名称空间。）

可读性比标记长度更重要。虽然 IXRetail 一直在担心长标记将使 XML 文档不切实际的长，但重要的是帮助用户选择正确的标记。例如，相对于 ID_DPT_POS，应首选 POSDepartmentID。（还可以预见“消息传递基础结构”将提供消息压缩。）

除了几个例外，在元素、属性和类型名称中不应使用缩写词和首字母缩略词。这些例外是：GTIN、ID 和 POS 分别表示 Global Trade Item Number、Identifier 和 Point of Sale。ARTS 数据模型的逻辑视图中避免使用缩写词。只有列出的几个例外才是允许的。这个指导原则还被认为适合于 XML 消息组件的名称。（很明显，这里列出的几个例外是特定于零售业的；其它行业可能允许有其它缩写词。）

尽可能地从属性名称中除去实体名称。在 ARTS 数据模型中，实体名称经常作为属性名称的前缀。这样使得在关系数据库模型中导入外键更方便。但是，XML 消息的分层结构消除了模棱两可并使得没有必要重复实体名称。因而，实体名称的重复不必要地增加了标记的长度。虽然这条指导原则使用了 ARTS 数据模型的实体和属性术语，但是它应用到了 XML 的元素和属性名称中；数据模型属性能与 XML 消息中的元素或者属性相符。（指导原则 8 与这条指导原则相关并且是它的广义版本。）

在 XML 模式中使用 W3C 规范，而不使用 DTD 或者备选的模式语言。XML Schema 允许使用本地元素名称，但是 DTD 要求所有元素名称是全局唯一的。（用开放源码验证解析器进行自动解析的可能性也影响这条指导原则的采用。）

枚举值应只使用名称（不使用数字）并且用于枚举值的名称必须符合元素或者属性名称的指导原则。如果已有合适的名称，那么应该使用它们（而不是使用 IXRetail 创建新的名称）。优先使用 ISO 标准，而不是国家标准或者协会规范。由自然语言单词组成的名称能够暗示该值的含义。编号的枚举会引起不互操作的非标准扩展。（对这条指导原则的批评是，使用名称的要求强制选择自然语言。为这些名称选择的语言应该是对那些维护和扩充消息传递系统的人员有最大帮助的一种语言。但是，这些名称应限定为区分由信息技术系统单独处理的信息；向用户呈现的消息应总是用每个用户选择的语言来编写。这个指导原则不是避免使用好的用户界面的一个借口。）

枚举值应使用由英语单词组成的名称。通过合理选择单词，基于自然语言的名称能暗示其含义，但数值不能。这有助于同来源于使用英语单词的 ARTS 数据模型的名称保持一致。为了可用性需要由最终用户选择向他们显示的表示元素、属性和枚举值的单词，并且甚至可能需要为说英语的人员翻译这些单词。只能期望确实进行系统调试的程序员来直接处理 XML 消息。（有些行业可能不需要这条指导原则或者可能选择另一种语言。但是，不做选择可能导致使用与任意数字一样没有帮助的含义模糊的“单词”。）

名称中不应包括包含结构的名称的重复。容器提供了足够的上下文；在组件名称中使用它的名称是多余的并且不必要地增加了组件标记的长度。例如， 元素可以包含 元素，但是不应有重复包含结构名称（Customer）的 元素。（第四项建议与此指导原则相关，但它使用了数据建模术语。如果始终如一地使用重复，也是可以考虑的，但是很明显这导致了一个不受欢迎的实践。）

IXRetail 指定的所有模式会将它们声明的全局名称放在一个名称空间中；这将是 IXRetail 名称空间，它是 http://www.nrf-arts.org/IXRetail/namespace/。将 IXRetail 名称放在一个名称空间内避免了与我们用户可能需要的模式规范（来自其它源）的名称冲突。通过避免使用多个名称空间，IXRetail 可以更好地限制无意识的等效声明或者定义的出现。IXRetail 能检查这个名称空间内的每个全局名称是否具有唯一的声明或者定义。这条指导原则不限制导入使用其它名称空间的模式文档。（通过将它本身限制在一个名称空间上，使 IXRetail 受到约束，它要仔细复查添加到名称空间中的每一项。预期这个名称空间将会随着 IXRetail 标准化其它消息模式而一起发展。其它指导原则限制了全局名称的使用并且减少了遵循这条指导原则时遇到的困难。因为只有 IXRetail 可以批准使用它的名称空间 URI 的规范，所以每个其它规范的批准者都必须采用它自己的名称空间 URI。还讨论了终止这个 URI 的斜杠字符[“/”]。许多标准名称空间的名称没有以这个字符结束。要求提供这个 URI 的登记员提供一个不用在特定文件上的标识，因为已标识的资源会随时更改；登记员提供了目录的 URI。但是，名称空间是一个概念性的资源并且它的 URI 是用来命名它的而不是对它进行定位。名称空间既不是一个文件也不是一个目录；它的 URI 是否以斜杠结束不是很重要。）

IXRetail 产生的每个 XML 实例文档应指定一个缺省的名称空间，它应是 IXRetail 名称空间。使用缺省名称空间避免了对那个名称空间中的名称明确地添加前缀的需要。这样缩短了使用 IXRetail 名称空间中名称的标记。指定缺省名称空间还向 IXRetail 指定的 XML 模式文档用户提供了相应的示例。（很重要的是注意这条指导原则适用于“XML 实例文档”而不适用于“XML 模式文档”。指定特定消息的文档（比如示例交互案例）有意与指定模式（用于标准化的消息类型）的文档区别开。进行这样的区分可以清楚地将什么正在被标准化和什么是标准的应用程序示例区别开。在这个意义上，只引用模式并且不添加新的声明的 XML 消息是 XML 实例文档。）

IXRetail 产生的每个 XML 模式文档应指定一个缺省名称空间和一个目标名称空间，它们应都是 IXRetail 名称空间。这样提供了对 IXRetail 名称空间上的名称的一致引用。虽然这样要求为 W3C 的 XML Schema 规范中的名称明确添加前缀，但是它只增加模式长度，而不是实例文档的长度。它还使定义在 XML Schema 和相关的 XML 标准中的所有名称的处理相互一致：总是为 W3C 标准化的名称添加前缀。（由前一条指导原则，模式文档和实例文档是有区别的。按这种区分，XML 模式文档是添加新属性或者元素声明的 XML 文档。）

域专家认为可能重用一个类型，simpleType 或者 complexType 应全局地定义在名称空间中，而不是匿名地定义在 Element 声明中。因为通常不在标记中使用它们，类型名称可以与足够的词根和修饰语连接起来，从而在不必产生长标记的情况下标识合适的域。这与总是使用在标记中的元素名称区别开。因此，全局元素名称的可选择性使标记变长。（有时候类型名称在一个实例文档中使用，比如当用 xsi:type 指定一个具体元素的类型时。在这些情况下，类型名称长度确实影响消息的长度。）

模式应使用那些使用 type 属性或者内联类型定义（simpleType 或者 complexType）的嵌套元素，而不是引用全局元素的 ref 属性。应尽可能地使用局部元素命名，这样可以保持短的名称。应为具有良好定义含义的名称保留 IXRetail 名称空间的全局部分。应该用充足的词根和修饰语构造这些全局名称来识别它们的使用域。（指导原则 12 适用于当建议重用声明或定义时。指导原则 12 声明优先使用全局类型而不是全局元素。一个消息的最外层元素将有一个合适的全局名称，将那个消息与所有其它消息区别开。包含在消息中的元素总是拥有包含的消息的上下文。）

IXRetail 产生的模式的每个版本必须拥有它自己的 schemaLocation 属性的 URI 值，这个值不同于其它每个模式的其它每个版本的 URI 值；这个 URI 必须在 ARTS-NRF 同意的层次结构中（每个 schemaLocation 将是 UTF-8 文件的 URI，它在 http://www.nrf-arts.org/IXRetail/schemaLocation/ 的下面一级）。应指定 开放标记的 version 属性并且这个属性应有一个和 schemaLocation URI 值相同的字符串的值。schemaLocation 和 version 的值的指定应与模式批准、建立和发布相联系。遵循 W3C 使用的模式，这些值也应包括发布日期。甚至 IXRetail 模式的最初版本也应使用一些版本控制机制。使用与模式 - 发现机制（为验证解析器而进行了标准化）并行的版本机制是合人心意的。在名称中包含发布日期的 W3C 模式示例是：http://www.w3.org/TR/2001/REC-xmlschema-2-20010502。（XML 需要所有符合的 XML 处理器支持 UTF-8。几乎所有的文本处理工具也可以浏览或者读取 UTF-8，其中许多工具在处理 UTF-16 时出现问题。这条指导原则所假定的开发步骤可能不是对所有的组织都是合适的，一些组织可能已经建立了版本标识的约定，即不允许通过使用这里推荐的 version 来提供 schemaLocation 提示。）

在适当的时候，使用 ARTS XML 字典（ARTS XML Dictionary）中的名称，而不是创造新的名称。ARTS XML 字典是一张名称列表，这些名称最初来源于 ARTS 数据模型的逻辑视图的实体和属性名称。ARTS 数据模型的上下文为这些名称提供了重要的语义。必须仍旧选择这些名称并且与其它所有的指导原则一致地使用它们。IXRetail 模式中的名称也将添加到 ARTS XML 字典中。（这条指导原则有意利用 XML 技术来扩展领先它的数据库。IXRetail 和 ARTS 工作人员在转换数据字典和相关数据模型规范方面做了大量工作。虽然完成这些转换花了很大的精力，但是它们确保了 XML 规范与已经广泛部署在零售业的信息流和处理紧密关联。如果没有这些转换，那就需要更多的需求验证。而且，需求的聚集和验证可能是标准化处理中速度最慢的一部分，因为业界的领先者不愿意把高优先级需求告诉他们的竞争对手。）

在选择一个名称（它在名称空间中是全局性的）时，使用描述声明或定义好的名称的特定意义的组合名称。这条指导原则的目的是避免不恰当使用具有特定意义的常规术语。如果全局名称很简单，那么用户将倾向于认为它们具有常规的用途，甚至当选择这个类型来满足只是一个有限领域、工业部门或者地理区域的要求的时候。例如，不应定义 LineItem 全局具体类型，因为在销售线项（sales line item）和支付线项（tender line item）之间的信息组成部分中有明显的差别。（这条指导原则不适用于局部名称，它们也有使用的上下文来描述它们的意义并且它们不阻止具有不同上下文和不同意义的相同名称的其它用法。）

对不同于 IXRetail 名称空间的名称空间上的名称，使用一致的前缀。不对 IXRetail 名称空间使用前缀。只使用这些前缀和定义：
xml（在 XML 标准中定义）
xmlns（在 XML 标准的 Namespaces 中定义）
xs http://www.w3.org/2001/XMLSchema
xsi http://www.w3.org/2001/XMLSchema-instance

使缺省名称空间和前缀保持一致，这样有助于使包含的模式的含义与内联文本包含的含义相同，这样确保人们可以得出与验证解析器执行所得含义一样的结论。（指导原则 10 和 11 规定：IXRetail 名称空间应指定为缺省名称空间；因此，它的全局名称就不需要前缀。由于附加前缀的使用已经获得批准，因此可以将它们添加到这条指导原则中。）
这些指导原则的目标是协助标准化的 XML 模式的开发。重要的特性包括为描述性的值和（与以前的业界标准）保持连贯性而选择名称，使用局部命名使消息的大小保持合理以及制定更改计划。我们希望您可以在我们的成果中找到一些适合您需要的。

参考资料

请参加本文的论坛。
在 ARTS 主页上可以找到关于国家零售联盟的零售技术标准协会（ARTS）的更多信息。在上面，您还可以找到与 IXRetail 和 ARTS 的 XML Dictionary 的链接。
本文的原稿发布在 2001 年 6 月和 7 月的 STORES Magazine 上，可以查找六月文章和七月文章。
在使用 XML 模式定义元素的基础知识上可以学习如何使用 XML Schema。
要快速理解 XML Schema，请阅读 W3C 的 XML Schema Part 0: Primer。要仔细研究完整的语言描述，请阅读 XML Schema Part1: Structures 和 XML Schema Part 2: Datatypes。
查看与 XML 相关的 W3C 规范的范围，请参阅 W3C Extensible Markup Language。
查看例如验证解析器这样的工具，请参阅 Apache 软件基础。
XML and WebSphere Studio Application Developer, Part 1: Developing XML Schema 包含了使用 XML Schema 编辑器（XML Schema Editor，是一个可视工具，用于构建与 XML Schema 推荐规范（XML Schema Recommendation Specification）相符的 XML 模式）的要点。