为什么扩展只能放在 simpleContent 和 complexContent 容器中？答案

【问题标题】：Why can extensions only be placed in simpleContent and complexContent containers?为什么扩展只能放在 simpleContent 和 complexContent 容器中？
【发布时间】：2013-05-30 12:25:07
【问题描述】：

我很难理解在 XSD 中定义类型扩展和限制的格式的一些细微差别。根据W3Schools reference：

simpleContent 定义“对纯文本复杂类型或作为内容且不包含任何元素的简单类型的扩展或限制”
complexContent 定义“仅包含混合内容或元素的复杂类型的扩展或限制

我不清楚为什么 XSD 要求扩展和限制包含在这些容器之一中，此外，为什么仅扩展和限制需要它。如果必须在容器中定义所有“内容”，这对我来说会更有意义，但情况并非如此 - 对于基本类型，内容（sequences 等）被定义为complexType 容器。

以this example 为例，对我来说这似乎过于冗长：

<xs:complexType name="fullpersoninfo">
  <xs:complexContent>
    <xs:extension base="personinfo">
      <xs:sequence>
        <xs:element name="address" type="xs:string"/>
        <xs:element name="city" type="xs:string"/>
        <xs:element name="country" type="xs:string"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

为什么不能这样写呢？

<xs:complexType name="fullpersoninfo">
  <xs:extension base="personinfo">
    <xs:sequence>
      <xs:element name="address" type="xs:string"/>
      <xs:element name="city" type="xs:string"/>
      <xs:element name="country" type="xs:string"/>
    </xs:sequence>
  </xs:extension>
</xs:complexType>

甚至像这样？

<xs:complexType name="fullpersoninfo" extends="personinfo">
  <xs:sequence>
    <xs:element name="address" type="xs:string"/>
    <xs:element name="city" type="xs:string"/>
    <xs:element name="country" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

我假设它的定义方式一定有某种原因，但我找不到任何线索说明原因。

【问题讨论】：

如果你转到w3schools，restriction 元素都不包含在complexContent 和simpleContent 中。这是一个错字还是因为它们都包含在 simpleType 元素中？
我知道这个问题很老，但你的第三个例子在技术上是有效的。如 2.5.3 Empty Content (w3.org/TR/xmlschema-0/#emptyContent) 中所述，“定义为没有任何 simpleContent 或 complexContent 的复杂类型被解释为限制 anyType 的复杂内容的简写。”
@claytond 我使用 XSD 已经有一段时间了，但我认为您引用的规则不适用于我的示例，因为该规则仅适用于限制 anytype，而我的示例是从 personinfo 类型扩展而来的（或者至少这是意图）
@KevinK 你是对的。我忽略了“extends”参数，没有意识到它是用来表示基础的。

标签： xsd

【解决方案1】：

我认为您不会为复杂类型的 XML 语法找到任何有用的设计原理。可以说，那些设计 XML 语法的人通过您提到的元素来解决一些技术难题，并且没有明显更好的语法在工作组中获得共识。您可能想知道 simpleContent 和 complexContent 解决了哪些技术难题，这是一个合理的问题，但我怀疑是否有人愿意深入研究 XSD 的设计记录来回答这个问题。

一个简单的观察：扩展和限制的合法子代取决于父代是 simpleContent 还是 complexContent。这是使用 simpleContent 和 complexContent 类型的本地声明来完成的，没有它们是不可能的——至少，如果没有对 XML 语法进行非常彻底的重新设计，就不可能。

【讨论】：

【解决方案2】：

以 C. M. Sperberg-McQueen 的回答为基础，我认为有些（如果不是更多的话）与语言的限制有关（我猜是“技术困难”参考）；由于大多数语法都试图证明它们足以定义自己，想象一下在“模式的模式”中实际上可以做的事情有多少，考虑到我们今天在 1.0 版中仍然“享受”的限制。

许多人认为，他们可以通过针对 XMLSchema.xsd 验证 XSD 的 XML 来真正验证 XSD - 事实并非如此。

许多 XML Schema 设计提出了与您相同的问题；答案通常是作者希望通过解决语言的限制来最大化其模式规范的约束能力。

不知何故，我相信如果 1.0 中的功能与 1.1 相似，那么语法就会有所不同；该规范不会更容易理解......

为了更丰富，我还会探索其他模式语言规范，例如 RelaxNG 或 Schematron；也许是一些争论性的讨论... 一个很好的阅读可能是 Rick Jelliffe 对 XSD 的看法。

【讨论】：