W3C home > Mailing lists > Public > xmlschema-dev@w3.org > April 2002

RE: Schema Design: Composition vs Subclassing

From: Mark Feblowitz <mfeblowitz@frictionless.com>
Date: Tue, 16 Apr 2002 09:28:49 -0400
Message-ID: <4DBDB4044ABED31183C000508BA0E97F040ABA18@fcpostal.frictionless.com>
To: "'Paul Kiel'" <paul@hr-xml.org>
Cc: "Xmlschema-Dev (E-mail)" <xmlschema-dev@w3.org>
As you point out, in the case of OAGIS 8 we found the use of restriction to
be too burdensome - too many copies of the same (meta)content to maintain,
too many complications with particle derivation. Instead, we went with a lax
model (all elements optional), deferring minimal cardinality checking until
after validation (e.g., using Schematron). 

Until Schema's derivation by restriction improves (or until the IDEs offer
support for maintenance of derivations by restriction), we felt that this
was our only manageable option. 

As always, it depends upon your circumstances and your threshold of
maintenance pain. If your type is not widely used, and if you don't mind
maintaining replicated definitional content, and you aren't hampered by the
constraints on derivation by restriction, then you would probably favor a
lax base class plus restriction. 

But if you have a situation where the class is widely used (as in Person),
and/or where you want to both restrict (to nail down the cardinality
constraints) and extend (to add more content), and/or where your type
hierarchy will be used in substitution groups, you may end up needing to
approaching things differently, either by creating a variety of accidentally
related types (PersonBlend1, PersonBlend2,...), or by external constraint

In the case of restriction plus extension, you'll have to do that in
multiple derivation steps: PersonAbstract -> PersonConstrained1 ->
PersonConstrained1Extended.  That gets ugly fast.

And if your substitution group base is of type PersonAbstract and your
substitution element is of type PersonConstrained1Extended, you'll likely
run into derivation problems.


Mark Feblowitz                                   [t] 617.715.7231
Frictionless Commerce Incorporated     [f] 617.495.0188 
XML Architect                                     [e]
400 Technology Square, 9th Floor 
Cambridge, MA 02139 

 -----Original Message-----
From: 	Paul Kiel [mailto:paul@hr-xml.org] 
Sent:	Monday, April 15, 2002 2:04 PM
To:	xmlschema-dev@w3.org
Subject:	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:
     <Name/><!-- required -->
     <Skills/><!-- required -->
     <Height/><!-- required -->
     <Weight/><!-- required -->
In this transaction, we need all the data about this person to do the

Transaction 2:
     <Name/><!-- required -->
     <Skills/><!-- optional -->
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

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 09:40:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:56 UTC