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

Re: [RESEND] Derivation by restriction

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 1 Apr 2002 16:44:29 +0100
Message-ID: <1032711318.20020401164429@jenitennison.com>
To: "Roger L. Costello" <costello@mitre.org>
CC: xmlschema-dev@w3.org, Simon.Cox@csiro.au
Hi Roger,

> Now let's examine the new design pattern. As I understand it, the
> first step is to embed the abstract element within a complexType,
> e.g.,
> <xsd:complexType name="PublicationContainer">
>     <xsd:sequence>
>         <xsd:element ref="Publication"/>
>     </xsd:sequence>
> </xsd:complexType>
> And then other complexTypes are created which restrict this type, by
> replacing the abstract element with a substitution group element, e.g.,
> <xsd:complexType name="BookContainer">
>     <xsd:complexContent>
>         <xsd:restriction base="PublicationContainer">
>             <xsd:sequence>
>                 <xsd:element ref="Book/>
>             </xsd:sequence>
>         </xsd:restriction>
>     <xsd:complexContent>
> </xsd:complexType>
> As the next step I assume you would then declare Catalogue to be of
> type PublicationContainer:
> <xsd:element name="Catalogue" type="PublicationContainer"/>
> Correct?

Well, you could do, but to get the benefit of BookContainer, then you
need an element that should only contain books, for example

<xs:element name="BookCatalogue" type="BookContainer" />

and then another element, say, that only contains Magazines, for
example MagazineCatalogue:

<xs:element name="MagazineCatalogue" type="MagazineContainer" />

(with the definition of MagazineContainer being like that for
BookContainer, but with Magazines instead.)

This enables us to represent both the conceptual hierarchies within
the schema, one for the items and one for the containers:

    Publication                   PublicationContainer
      /     \                       /              \
    Book  Magazine           BookContainer   MagazineContainer

And within the instance to have:

  <BookCatalogue>                <MagazineCatalogue>
    <Book> ... </Book>             <Magazine> ... </Magazine>
    <Book> ... </Book>             <Magazine> ... </Magazine>
  </BookCatalogue>               </MagazineCatalogue>

Note that the PublicationContainer complex type, like the Publication
complex type is usually abstract in this pattern, and there usually
won't be a basic Catalogue element that allows all publications.
However, you could equally have:

  <Catalogue xsi:type="BookContainer">
    <Book> ... </Book>
    <Book> ... </Book>

I think that the utility of representing the container-type hierarchy
is just like the utility of representing any other hierarchy within a
schema - I assume that at some point during processing people who use
this pattern use the fact that both BookContainer and
MagazineContainer are PublicationContainers.


Jeni Tennison
Received on Monday, 1 April 2002 10:44:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:56 UTC