Re: [Gml30.rwg] RE: [RESEND] Derivation by restriction

Comment below:

Simon.Cox@csiro.au wrote:

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

Why not use a choice?

<xsd:group name="geometryContainer">
  <xsd:choice>
    <xsd:element ref="PolygonContainer"/>
    <xsd:element ref="CirlceContainer"/>
  </xsd:choice>
</xsd:group>

Don't forget that we are dealing with XML Schema. There are ways to do things
other than by restrictions and extensions and substitutionGroups.

>
>
> 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/
> >
> _______________________________________________
> Gml30.rwg mailing list
> Gml30.rwg@opengis.org
> http://mail.opengis.org/mailman/listinfo/gml30.rwg

--
John I. Bobbitt
Energy eStandards          Web: http://www.energyestandards.org
Off:(713)267-5174          Web: http://www.posc.org
Fax:(713)784-9219          mailto:bobbitt@posc.org
We are confronted with insurmountable opportunities.
                               -- Walt Kelly