Why can extensions only be placed in simpleContent and complexContent containers?

Question

I'm having difficulty understanding some of the nuances of the format for defining type extensions and restrictions in XSD. According to the W3Schools reference:

• simpleContent defines "extensions or restrictions on a text-only complex type or on a simple type as content and contains no elements"
• complexContent defines "extensions or restrictions on a complex type that contains mixed content or elements only

What isn't clear to me is why XSD requires extensions and restrictions to be contained in one of these containers, and furthermore, why only extensions and restrictions require it. It would make a little more sense to me if all 'content' had to be defined in the container, but this is not the case - with base types, the content (sequences, etc.) are defined as direct children of the complexType container.

Take this example, which to me seems overly verbose:

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

Why is it not possible to write it like this instead?

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

Or even like this?

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

I'm assuming there must be some reason it was defined the way it was, but I can't find any clues as to why.

Answer 1

I don't think you're going to find any useful design rationales for the XML syntax of complex types. Suffice it to say that those designing the XML syntax managed, by means of the elements you mention, to solve some technical difficulties, and that no obviously better syntax commanded consensus in the working group. You may wonder what technical difficulties are solved by simpleContent and complexContent, and that's a reasonable question, but I doubt anyone is going to be willing to undertake the excursion into the design records of XSD that would be necessary to answer it.

One simple observation: the legal children of extension and restriction vary depending on whether the parent is simpleContent or complexContent. That is accomplished using declarations local to the types of simpleContent and complexContent and would not be possible without them -- at least, not without a very thorough redesign of the XML syntax.

Answer 2

To build on C. M. Sperberg-McQueen's answer, I would think that some (if not more) had to do with the limitations of the language (I guess the "technical difficulties" reference); since most grammars try to prove that they're good enough to define themselves, imagine how little could've actually be done in the "schema for schema", considering the limitations we still "enjoy" today in version 1.0.

Many people believe that they could truly validate an XSD by validating the XML that is XSD against the XMLSchema.xsd - it is not the case.

Many XML Schema designs raise the same question as yours; the answer is typically that the author wanted to maximize the constraining capabilities of their schema spec by working around limitations in the language.

Somehow I believe that if the features in 1.0 would have been similar to 1.1, the syntax would've been different; the spec wouldn't have been easier to understand...

To make this richer, I would also explore other schema language specifications, such as RelaxNG or Schematron; maybe some argumentative discussions... A good reading is probably Rick Jelliffe take on XSD.