RE: [RESEND] Derivation by restriction

Thanks Jeni - yes, this is exactly the point.  

In the GIS schemas that we are developing, there 
is a need to assert that (e.g.) triangle-container 
and rectangle-container are both polygon-containers.  
This is exactly the reason we are trying to use this trick.  

In this case it works fine since triangle and rectangle 
are both clearly a restriction of polygon (they have a 
prescribed number of nodes, rather than "unbounded"). 
 
But we also need to move up one step:  
we need for circle-container and polygon-container 
to both be geometry-containers.  

But the definition of a circle (i.e. a centre and radius) 
and polygon (a list of coordinates) do not have an obvious 
common ancestor from which they can both be derived by restriction.  
So we had defined GeometryType as a (more or less) 
empty abstract super type, and then derived CircleType 
and PolygonType by extension.  

This is where we hit the wall, since using XSD we now 
cannot define circle-container and polygon-container 
as restrictions of geometry-container ... the types of 
the content particles are not restrictions of the 
type of the content particle in the base type.  


This is a genuine problem that is holding up a major 
project in the Open GIS Consortium.  
It is causing us to question whether we can continue 
to use XSD as a "conceptual schema language".  
So if anyone has any insights or suggestions of better 
patterns to use, we would love to hear.  

_____
[This mail represents part of a discussion of work in progress 
and should not be used for any purpose without my permission.] 
_____
Simon.Cox@csiro.au  CSIRO Exploration & Mining
26 Dick Perry Avenue, Kensington WA 6151
PO Box 1130, Bentley WA 6102  AUSTRALIA
T: +61 (8) 6436 8639  F: +61 (8) 6436 8555  C: +61 (4) 0330 2672
http://www.csiro.au/page.asp?type=resume&id=CoxSimon

> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com]
> Sent: Monday, 1 April 2002 11:44 PM
> To: Roger L. Costello
> Cc: xmlschema-dev@w3.org; Simon.Cox@csiro.au
> Subject: 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 19:43:30 UTC