10

在 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”在实例文档将使用正确的类型对其进行验证。）对吗？

此功能还有其他用途吗？

4

1 回答 1

11

您的第一个问题是“在 XML Schema 中为 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 中的几乎所有内容都是如此。它唯一真正的优点是它得到了很多人似乎想要使用的许多工具的支持。

于 2013-02-10T18:53:20.467 回答