- 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