W3C home > Mailing lists > Public > xmlschema-dev@w3.org > August 2002

Re: [xml-dev] Re: Complex or Simple content usage

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 12 Aug 2002 13:36:18 +0100
Message-ID: <113379922018.20020812133618@jenitennison.com>
To: "Roger L. Costello" <costello@mitre.org>
CC: xmlschema-dev@w3.org, Danny Vint <dvint@mindspring.com>

Hi Roger,

> Are you sure about this? I thought the rules for this were real
> simple:
>
> complexContent extends/restricts complexTypes
> simpleContent extends/restricts simpleTypes
>
> This looks correct to me:
>
>      <xsd:element name="HelpText">
>         <xsd:complexType>
>            <xsd:complexContent>
>               <xsd:extension base="C-255">
>                  <xsd:attribute ref="xml:lang"/>
>               </xsd:extension>
>            </xsd:complexContent>
>         </xsd:complexType>
>      </xsd:element>
>
> "HelpText extends the complexType, C-255, with the attribute,
> xml:lang."  Looking at C-255 we see that it is a simple type extended
> with an id attribute.  Thus, <HelpText id=".."
> xml:lang="..">...</HelpText>

Ergh, sorry, I think you're right that this is legal. The reason that
this exception is allowed is because the {content type} of the complex
type definition is the simple type definition xs:string since there's
no explicit content.

If it were:

     <xsd:element name="HelpText">
        <xsd:complexType>
           <xsd:complexContent>
              <xsd:extension base="C-255">
                 <xsd:sequence>
                   <xsd:element ref="Note" />
                 </xsd:sequence>
                 <xsd:attribute ref="xml:lang"/>
              </xsd:extension>
           </xsd:complexContent>
        </xsd:complexType>
     </xsd:element>

or something similar, then it wouldn't be legal, because clause 1.4 of
Derivation Valid (Extension)
http://www.w3.org/TR/xmlschema-1/#cos-ct-extends wouldn't be
satisfied.
     
> Can you point me to the part of the spec that allows simpleContent
> to extend a complexType?

The spec generally explicitly *disallows* things rather than
explicitly *allowing* them, so this might be a little tricky. But
starting with:

<xs:complexType name="C-255">
  <xs:simpleContent>
    <xs:extension base="xs:string">
      <xs:attribute name="id" type="xs:ID" />
    </xs:extension>
  </xs:simpleContent>
</xs:complexType>

Here, the {content type} of the complex type C-255 is the simple type
definition xs:string.

If we have:

<xs:element name="HelpText">
  <xs:complexType>
    <xs:simpleContent>
      <xs:extension base="C-255">
        <xs:attribute ref="xml:lang"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
</xs:element>

then the {content type} of the derived complex type is defined with:

  2 otherwise if the type definition ·resolved· to by the ·actual
  value· of the base [attribute] is a complex type definition (whose
  own {content type} must be a simple type definition, see below) and
  the <extension> alternative is chosen, then the {content type} of
  that complex type definition;

So the {content type} of the complex type definition is (again) the
simple type definition, and the rest of the logic follows through
exactly as it does with the xs:complexContent instead.

If you look at the way the {content type} of the complex type is
defined under a *restriction*, you'll see that if you specify complex
content, for example:

  <xs:complexType>
    <xs:complexContent>
      <xs:restriction base="C-255">
        ...
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

then you can't restrict the string using facets (xs:restriction within
xs:complexContent doesn't include facets), and, indeed, you end up
with something with an empty {content type}, which means it's invalid
since you can't derive empty content from simple content (per clause
5.2 of http://www.w3.org/TR/xmlschema-1/#derivation-ok-restriction).

On the other hand, if you use xs:simpleContent, everything works out
fine.

So I think that the rules:

> complexContent extends/restricts complexTypes
> simpleContent extends/restricts simpleTypes

are wrong, and you're better off with:

  complexContent extends/restricts
    complex types with complex content
  
  simpleContent extends/restricts
    simple types or complex types with simple content
  
> P.S. Congrats on your new book and award!

Thank you ;) The "trophy" arrived today -- a beautiful cocktail shaker
with my name on it; I'm delighted.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Monday, 12 August 2002 08:36:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:34 GMT