复杂类型的 XML 架构限制 : Complete Redefinition?

Question

在 XML Schemas 中对 complexTypes 添加限制时，是否需要重写 complexType 定义中使用的所有元素？如果是这样，为什么它不能重用现有的元素定义并覆盖新的受限元素？

例如，在下面；当我只想限制字段 country 时，我是否需要将这 3 个字段全部重写一遍？

<xs:complexType name="customer">
  <xs:sequence>
    <xs:element name="firstname" type="xs:string"/>
    <xs:element name="lastname" type="xs:string"/>
    <xs:element name="country" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="Norwegian_customer">
  <xs:complexContent>
    <xs:restriction base="customer">
      <xs:sequence>
        <xs:element name="firstname" type="xs:string"/>
        <xs:element name="lastname" type="xs:string"/>
        <xs:element name="country" type="xs:string" fixed="Norway"/>
      </xs:sequence>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType> 

所以，从下面的答案中很清楚为什么我们必须重写整个类型。

跟进问题

那么这个限制功能有什么用呢？

一种情况，我能想到；是当您必须验证包含受限类型以代替 xml 模式中的基本类型的实例文档时。

比如说，如果“B”是基本类型并且它被限制为“B*”。任何在模式文档期望类型为“B”的元素的位置包含“B*”的实例文档都可以工作。我们不必为每个受限类型编写单独的规则。(属性“xsi:type”在实例文档将使用正确的类型验证它。)对吗？

此功能的任何其他用途？

Answer 1

您的第一个问题是“在 XML Schemas 中对 complexTypes 添加限制时，是否需要重写 complexType 定义中使用的所有元素？”不，只有那些你想成为受限类型定义的一部分。但是，是的，所有这些都应该成为限制的一部分。限制中的内容模型必须作为类型内容模型的完整定义独立存在。 (另一方面，它不必指定所有属性；除非另有说明，否则它们将被继承而不会更改。)

你的第二个问题是“为什么它不能重用现有的元素定义并覆盖新的受限元素？”这是一个合理的问题。答案有点棘手:考虑两个任意内容模型 E 和 F。现在，我们想将 F 解释为 E 的限制，它仅提及 E 中我们想要更改的元素和模型组，并忽略任何提及的元素和我们想要的模型组。在一般情况下，这是一个可解决的问题吗？是否保证有唯一解？对您来说，这两种情况的答案都是肯定的，但对当时的 XSD 设计者来说似乎并不明显，对今天的我来说似乎也不明显。

例如设E为

(a+, b+, c*){2}, (a+, b*, c+){3}

设F为

a{3,4}

如果我们假设 F 中的所有内容都是对 E 中某些内容的限制，而 E 中的其他所有内容都应该保持不变，那么 F 是否意味着我们要将 E 限制为

(a{3,4}, b+, c*){2}, (a+, b*, c+)

或到

(a+, b+, c*){2}, (a{3,4}, b*, c+)

?

附录

@nikel 要求提供 XSD 示例。不过，上面的示例已经是一个 XSD 示例，因此我认为“XSD 语法示例”是指。我认为像下面这样的语法应该有效。首先我们有基本类型，E:

<xs:complexType name="E">
  <xs:sequence>
    <xs:sequence minOccurs="2" maxOccurs="2">
      <xs:element ref="a" maxOccurs="unbounded"/>
      <xs:element ref="b" maxOccurs="unbounded"/>
      <xs:element ref="c" minOccurs="0" 
                          maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:sequence minOccurs="3" maxOccurs="3">
      <xs:element ref="a" maxOccurs="unbounded"/>
      <xs:element ref="b" minOccurs="0" 
                          maxOccurs="unbounded"/>
      <xs:element ref="c" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:sequence>
</xs:complexType>

现在让我们想象一下，我们希望类型 F 能够在不指定完整内容模型的情况下限制 E。所以我们写

<xs:complexType name="F">
  <xs:complexContent>
    <xs:restriction base="tns:E">
      <xs:sequence>
        <xs:element ref="a" minOccurs="3" maxOccurs="4"/>          
      </xs:sequence>        
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

这里F的有效内容模型应该是什么？

跟进问题

您基本上会问，“在那种情况下，限制有什么用？”

合理的问题。您建议的答案是一个很好的答案。更一般地说，有时我们发现知道类型 B* 的每个实例都将是类型 B 的实例很有用； XSD 中的限制推导旨在保证不变性。有时定义一个具有两个或更多具体限制的抽象类型似乎很有帮助；这有助于确保抽象基类型的各种具体实现彼此很好地相关，即使没有一个是任何其他的子集或超集。

在 XSD 中，可能有(不:有很多)限制派生的方法可以变得更清晰、更简单、更方便；不必重复整个内容模型就是其中之一。但是，对于 XSD 中的几乎所有内容都是如此。它唯一真正的优点是它得到许多人似乎想要使用的许多工具的支持。