- From: zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN <michael.marchegay@rd.francetelecom.com>
- Date: Wed, 22 May 2002 14:13:20 +0200
- To: "'Jeni Tennison'" <jeni@jenitennison.com>
- Cc: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
- Message-ID: <0489A7888F080B4BA73B53F7E145F29A1B0ABE@LANMHS20.rd.francetelecom.fr>
Hi Jeni, > > > Hi Michaël, > > > I'm trying to understand the interest of complexContent > > restrictions, but I don't find in which kind of examples it is > > usefull. > [snip] > > I can't figure out what is the difference between an element which > > has type simpleName1 and another which has type simpleName2. > > > > So are complexContents just syntaxic sugar, used by XML Schema > > processing tools or do they have another function? > > You're absolutely right that in your example, the simpleName1 and > simpleName2 complex types have exactly the same content model, so > elements of those types are allowed exactly the same content. > > However, the fact that simpleName1 is derived from personName can be > significant. For example, if you were to declare an element with the > type personName: > > <xsl:element name="name" type="personName" /> > > then an instance of that element could be assigned the type > simpleName1 through the xsi:type attribute: > > <name xsi:type="simpleName1">...</name> > > whereas it couldn't be assigned the type simpleName2. > So a complexContent is usefull only when used in a type declaration, isn't it ? If I use one in a "inline" type definition for an element: <xs:element> <xs:complexType> <xs:complexContent> <xs:restriction base="personName"> <xs:sequence> <xs:element name="surname"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> this has **exactly** the same signification as if I write <xs:element> <xs:complexType> <xs:sequence> <xs:element name="surname"/> </xs:sequence> </xs:complexType> </xs:element> isn't it ? Thanks. > Similarly, an element called simpleName could belong to the name > element's substitution group if it had the type simpleName1 (because > that's derived from the name element's type) but not if it had the > type simpleName2. > > So within the schema itself, and in terms of what you can do in the > instance document, the fact that one of the types is derived from > personName and the other isn't can make a significant difference. > > The other way in which the type hierarchy can help is within > processing tools that are aware of the PSVI. XSLT 2.0, for example, is > on its way to becoming such a tool, which would mean that you'd be > able to match all elements of type personName or simpleName1 with: > > <xsl:template match="*[. instance of personName]"> > ... > </xsl:template> > > whereas simpleName2 is unrelated to personName. > > Thus, deriving by restriction is helpful because it enables you to > express the commonality between a set of elements, and process them in > the same kind of way. > > Cheers, > > Jeni > > --- > Jeni Tennison > http://www.jenitennison.com/ -- Michaël Marchegay, Stagiaire France Telecom R&D du 11/02/2002 au 26/07/2002 Sous la responsabilité d'Olivier Dubuisson DTL/TAL - 22307 Lannion Cedex - France >
Received on Wednesday, 22 May 2002 09:17:11 UTC