- 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