- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Mon, 12 Aug 2002 13:36:18 +0100
- 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 UTC