Re: Schema Design: Composition vs Subclassing

Great discussion Roger et al!

I have a question about the effect of this best practice.  It is regarding
context-specific use of components.  Let's take the element <Person> in a
human resources context.  (BTW - <Person> is too broad a concept to actually
encode, this is only for discussion).  We may want to use a <Person> in many
contexts, where some of its components are required in one and not in
another.  Let's say we have two transactions of Person below (and that all
children are stand alone components):

Transaction 1:
<Person>
     <Name/><!-- required -->
     <Skills/><!-- required -->
     <Height/><!-- required -->
     <Weight/><!-- required -->
</Person>
In this transaction, we need all the data about this person to do the
transaction.

Transaction 2:
<Person>
     <Name/><!-- required -->
     <Skills/><!-- optional -->
</Person>
In this transaction, we only need a name of the person and the skills are
optional.  The Height and Weight have no meaning in this context and can't
occur.

Given these kinds of scenarios, are we to:
1) have many versions of <Person> with different occurrence constraints
based on context (many small blocks and few big blocks)
2) build a <Person> that has everything and list contextual constraints
externally (the OAGIS 8 design)
3) build an abstract <Person> and derive by restriction (the best practices
argues quite effectively NOT to do this)
4) decoupling of efforts.  Create an abstract <Person> with everything in
one schema and no constraints.  Meanwhile, in actual transactions, use
context-specific <Person> with constraints as needed which matches the
abstract <Person> but without doing it explicitly via restriction.  This way
you get to build a broader model for others to reuse but without the tight
coupling that is expressed on Roger's Best Practices site.
5) others?

Which of these would you think is best?

Thanks again for a great discussion.

Paul Kiel


W. Paul Kiel
HR-XML Consortium






----- Original Message -----
From: "Roger L. Costello" <costello@mitre.org>
To: <xmlschema-dev@w3.org>
Cc: "Jeni Tennison" <jeni@jenitennison.com>; <paul.w.daisey@census.gov>;
<Simon.Cox@csiro.au>; <costello@mitre.org>
Sent: Monday, April 15, 2002 8:37 AM
Subject: Re: Schema Design: Composition vs Subclassing


> Hi Folks,
>
> A couple of weeks ago I raised the topic: which approach is to be
> favored - design by subclassing or design by composition.  There were
> numerous responses, largely in favor of subclassing.
>
> Since that time I have gone off and done some thinking and researched
> how this design issue is approached in the Object-Oriented field.  As a
> result I have now convinced myself that composition should be the
> favored approach (as it is in the OO field).  I have written up this
> issue and posted it on the BestPracticesHomepage:
>
> http://www.xfront.com/composition-versus-subclassing.html
>
> Any comments on this would be appreciated.
>
> The paper addresses most of the issues that were raised a couple of
> weeks ago.  The one issue that it does not address I do so here:
>
> > I think that design-by-subclassing has one killer advantage,
> > namely that applications can use information about the type hierarchy
> > in order to provide common processing for all elements of a particular
> > (high level) type.
>
> My response to this is to quote from the Design Patterns book by Gamma
> et al: "Delegation is a way of making composition as powerful for reuse
> as inheritance.  In delegation, two objects are involved in handling a
> request: a receiving object delegates operations to its delegate.  This
> is analogous to subclasses deferring requests to parent classes."
>
> /Roger
>
>

Received on Tuesday, 16 April 2002 03:01:39 UTC