RE: XML Schemas: Best Practices

["Arnold, Curt" <Curt.Arnold@hyprotech.com>]

All of your examples these would fall under that pattern that I called projection.    Basically, that each subclass is rendered as an element that contains all the information from all the
superclasses and the subclass.

Aggregation would be if you had a <Publication> element that contained generic publication data and could contain child elements that contained book or magazine specific information.

<Catalogue>
        <Publication>
		<Book>
                <ISBN>0-440-34319-4</ISBN>
                <Publisher>Dell Publishing Co.</Publisher>
		</Book>
            <Title>Illusions The Adventures of a 
                       Reluctant Messiah</Title>
            <Author>Richard Bach</Author>
            <Date>1977</Date>
        </Publication>
        <Publication>
		<Magazine/>
            <Title>Natural Health</Title>
            <Date>1999</Date>
        </Publication>
...
</Catalogue>


Decoration would be if you had a Publication element that contained generic publication data and could be enveloped by elements that added book or magazine specific information.

<Catalogue>
	<Book>
           <ISBN>0-440-34319-4</ISBN>
           <Publisher>Dell Publishing Co.</Publisher>
           <Publication>
            	<Title>Illusions The Adventures of a 
                       Reluctant Messiah</Title>
            	<Author>Richard Bach</Author>
            	<Date>1977</Date>
        	</Publication>
	</Book>
	<Magazine>
        	<Publication>
            	<Title>Natural Health</Title>
            	<Date>1999</Date>
        	</Publication>
	</Magazine>
...
</Catalogue>


The advantage of the aggregation pattern is that new types of publications (CD-ROM's, CD's, DVD, videotape, etc) could be added after the system is deployed and you could still search all publications
by title.  If you used a projection pattern, then deployed applications would probably have to be updated (or have access to  meta-information) to know that a <DVD> is also a publication and has a
title.

There are definitely cases where you use an <choice/> group where you are not asserting some common abstraction, however this discussion assumes that there is some common abstraction shared between
the potential choices.

In your example, you are discussing two classes/elements that share a common structure.  This would be the classic OOP inheritance situation.

class Publication {};
class Magazine extends Publication {};
class Book extends Publication {};

The other case that needs to be considered is when the classes do not share a common structure.  For example, if you were using a Book and Magazine element from distinct schemas from different
organizations.  In an OOP, this would either be accomplished using an interface:

class org.AmericanBookPublishers.Book implements org.PublicationSeller.Publication {}
class org.AmericanMagazinePublishers.Magazine implements org.PublicationSeller.Publication {}

or an adapter

class BookAdapter extends Publication {
	private Book _book;
}

class MagazineAdapter extends Publication {
	private Magazine _magazine;
}

Also, supporting a MagazineRef or BookRef element may cause the situation to arise when you have structurally-dissimilar elements that are conceptually substituable.

>Method 1. Use an abstract element and element substitution to 
>achieve variable content.

Substitution groups that the substituable elements have a common ancestor type.  This makes this method unusable when you are trying to use elements from uncoordinated schemas.  For example, I may be
building a schema and I have an abstraction "Things In Garages" and car, bicycle and Christmas Tree are all members.  Unless the authors of the car, bicycle and Christmas Tree schemas coordinated to
use a common ancestor, I can't effectively use substitution groups.

You also have to jump through some hoops to use substitution groups when you are defining your own elements that are conceptually similar but structurally dissimilar (like a Magazine and MagazineRef
element).  In this case, you would have to create a common ancestor complex type (AbstractMagazine) with very little structure (since they would share almost none) and add in the publication or
reference structure using model groups and attribute groups instead of extending a Reference or Publication complex type.

Method 1 is particular good when you are writing a schema that you expect others to extend but doesn't not depend extensively on preexisting schemas.

>Method 2. Use a repeatable <choice> element to achieve variable
> content.

Eliminates the common ancestor type restriction of element substition.  Good when you are cobbling together schemas from disjoint sources, but does not let people extend your schema easily.

>Method 3.  Use an abstract type and type substitution to achieve 
>variable content.

Has same weakness as Method 1.  Hard to do equivalent validation with DTD's.  Someone else will have to suggest where this could be better than Method 1.