No argument with your posting (I decided not to post a similar statement
after rereading yours), but could you change your terms slightly?
Although the OO terms themselves were definitely conflated during the
eighties they have by now settled down to:
Type: The declaration of the interface of any set of [objects] that
conforms to this common protocol. Any set of objects or values
with similar behavior... [Firesmith+E 95]
Class: A class is the realization of a type. [UML] The idea of
class is closely linked...with the description of implementation details
of software objects [Cook+D 94].
Type vs. Class: Types classify objects according to a common
interface; classes classify objects according to a common implementation.
[Firesmith+E 95]
Subtyping: The incremental definition of a new type in terms of one
or more existing types, whereby the subtype conforms to all of its
supertypes [an is-kind-of relationship] [Firesmith+E 95]
And subclassing implies implementation-inheritance (i.e. code reuse),
exactly what you were trying to avoid implying.
So I would suggest rewriting your example to:
> > Anyhow, you can emulate OTHER using subtyping without an explicit
> > OTHER construct.
> >
> > <!ELEMENT CITATION (name, author, date, OTHER-CIT* )>
> > <!ELEMTYPE OTHER-CIT> <!-- no constraints on subtypes -->
> > <!ELEMTYPE ANOTHER-TYPE ISA ANY> <!-- Be explicit about the
automatic root -->
> >
> > <!ELEMENT URL (#PCDATA) ISA (OTHER-CIT & ANOTHER-TYPE)>
Which makes it use the standard terminology.
So, ELEMENTs would be the leaves of a tree/digraph of Types with ANY as
the root. Note that ISA should formally be IS-A-KIND-OF but that is an
annoyingly long keyword. (My dog is-a Dog which is-a-kind-of Mammal vs:
My dog is-a Dog which is-a Mammal).
--Mark
mark.fussell@chimu.com
i ChiMu Corporation Architectures for Information
h M info@chimu.com Object-Oriented Information Systems
C u www.chimu.com Architecture, Frameworks, and Mentoring