Question

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

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

我不清楚为什么XSD需要在其中一个容器中包含扩展和限制，以及为什么仅扩展和限制需要它。如果必须在容器中定义所有“内容”，那对我来说会更有意义，但事实并非如此 - 对于基类型，内容（sequence s等）被定义为直接complexType容器的子项。

拿W3Schools reference，这对我来说似乎过于冗长：

<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>

我假设必须有某种原因它的确定方式，但我找不到任何关于原因的线索。

Answer 1

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

一个简单的观察：延伸和限制的合法子女取决于父母是简单内容还是复杂内容。这是使用simpleContent和complexContent类型的本地声明来实现的，没有它们是不可能的 - 至少，没有非常彻底的重新设计XML语法。

Answer 2

在C. M. Sperberg-McQueen的回答的基础上，我认为有些（如果不是更多）与语言的局限性有关（我猜“技术难点”参考）;因为大多数语法都试图证明它们足够好以定义自己，想象一下在“模式架构”中实际上做得多么少，考虑到我们今天在版本1.0中仍然“享受”的限制。

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

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

不知怎的，我相信如果1.0中的特征与1.1类似，那么语法会有所不同;规范不容易理解......

为了使其更丰富，我还将探索其他模式语言规范，例如RelaxNG或Schematron;也许是一些争论性的讨论...... Rick Jelliffe很可能会对XSD有所了解。

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

2 个答案: