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

Re: [RESEND] Derivation by restriction

From: Roger L. Costello <costello@mitre.org>
Date: Tue, 02 Apr 2002 12:30:53 -0500
Message-ID: <3CA9EACD.B138BF8A@mitre.org>
To: Jeni Tennison <jeni@jenitennison.com>
CC: xmlschema-dev@w3.org, Simon.Cox@csiro.au, costello@mitre.org
Thanks a lot Jeni for your clear and thoughtful response.  Also, thanks
to Simon and Eddie for their inputs.  

I have summarized our discussions and put it on the
BestPracticesHomepage:

http://www.xfront.com/ElementHierarchy.html

Let me know if I am in error on anything.  

Thanks again!  /Roger

Jeni Tennison wrote:
> 
> 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 Tuesday, 2 April 2002 12:31:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:30 GMT