Re: [RESEND] Derivation by restriction

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
BookCatalogue:

<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>
  </Catalogue>

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.
  
Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

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