Re: Schema Design: Composition vs Subclassing

Digression: The design-by-composition term didn't hit me right since I'd
used similar terminology to describe using a child element in an instance
document to effectively subtype the resulting object.  Something like:

<part partno="XXX">
    <!--  this element effectively subtypes part,
                but by expressing it this way processors that have no
knowledge or
                radio still know it is a part   -->
    <radio am="true" fm="true" xm="true" xirius="false"/>
</part>

There was a decent amount of tension (at least from an outside observers
point of view) in the draft period that type derivation and the groups
functionally overlapped and that one or the other could be eliminated.  I'm
pretty glad that the groups weren't eliminated.

The one relative weakness of the groups over type declaration is that there
is not an technique equivalent to equivClasses to support modularization
using groups.  In the draft phase, I had proposed that equivClass
functionality could be accomplished with an "open" or "implicit" choice
groups that did not place any structural or derivation constraints on the
members.  This is similar to using an interface to allow substituability of
classes that have no deep structural similarity.  With equivClasses, you may
have to go through some pretty substantial hoops to fabricate and retrofit a
common base type into the inheritance hierarchy of elements that you wanted
to be substitutable.

If there was anything that I'd like added in XML Schema 1.1, it would be the
ability to do something like:

<xsd:group open="true" name="foos">
    <!--  group type must not depend on order -->
    <xsd:choice/>
<xsd:group>

In some other schema:

<xsd:element name="fooRef" groups="other:foos">
...
</xsd:element>

Received on Wednesday, 3 April 2002 11:33:39 UTC