RE: [RESEND] Derivation by restriction

The coverage looks pretty good. It takes some getting used to, but it can be
a powerful design pattern. We've used it pretty heavily in our OAGIS
redesign work.

We did encounter some difficulty in applying it across namespaces. Once you
introduce separate namespaces and then try to derive by restriction across
namespace boundaries, all kinds of trouble starts. 

In some cases, the reason for using substitution groups is precisely because
you can get a certain kind of extensibility without having to restrict along
the way. But the minute you need to subset the substitution group, you end
up having to create restriction steps down the containment hierarchy. And if
that crosses a namespace boundary, all particle derivation bets are at risk.

I'm not sure if this is an issue in your examples - they seem pretty
straight-forward. 

When I have a few spare cycles, I'll try to demonstrate the difficulties.

Mark


----------------------------------------------------------------------------
----
 
Mark Feblowitz                                   [t] 617.715.7231
Frictionless Commerce Incorporated     [f] 617.495.0188 
XML Architect                                     [e]
mfeblowitz@frictionless.com
400 Technology Square, 9th Floor 
Cambridge, MA 02139 
www.frictionless.com  
 

 -----Original Message-----
From: 	Roger L. Costello [mailto:costello@mitre.org] 
Sent:	Tuesday, April 02, 2002 12:31 PM
To:	Jeni Tennison
Cc:	xmlschema-dev@w3.org; Simon.Cox@csiro.au; costello@mitre.org
Subject:	Re: [RESEND] Derivation by restriction

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 14:33:58 UTC