Inheritance in XML [^*]

W. E. Perry wperry at fiduciary.com
Fri Apr 24 00:02:46 BST 1998



Lisa Rein wrote:

> >
> > What are two properties? Type and class? Did you shift from discussing
> > properties "concerning" type and class and type and class *as* properties.
> >
> > Can you also please defend the distinction between type and class? It
> > makes sense in object oriented programming languages (mostly for
> > performance reasons), but I don't know that there is any such distinction
> > in common usage or in most ontologies. I am prepared to be convinced
> > otherwise, but I think that the class/type distinction is specific to OOP
> > and is not useful except as an arbitrary distinction, to avoid confusion,
> > as it is used in the DSSSL spec. (node class, flow object class vs.
> > element type ... you could as easily reverse them and talk of element
> > classes and node types...)
>
> It was my understanding that they are all just different names for the
> same "things".  At least they are for RDF, right?  In fact, in the RDF
> Schema group, as far as the typing (classing) models were concerned,
> types and classes were exactly the same (so much so, in fact, that we
> went back and forth on which to call them and, conceptually anyway, the
> words became so interchangible -- Resulting in a "type system" of
> classes :-).  Also, the types/classes and their respective resources (of
> which RDF's mission is to describe) WERE classes and node types (that
> was my understanding anyway...).
>
> Just when I thought I finally had a clear understanding of the above,
> suddenly I'm not so sure.  Someone reassure me....please.

Paul Prescod dealt with this accurately and conclusively in his 20 Apr post:

Subject:
        Inheritance and subtyping in OO languages
   Date:
        Mon, 20 Apr 1998 09:20:12 -0400
   From:
        Paul Prescod <papresco at technologist.com>
     To:
        xml-dev <xml-dev at ic.ac.uk>

I've found a good reference to the 8 year old paper that made the
distinction between inheritance and subtyping most explicit. The paper
itself is not online, but this summary is quite good:

"[CCHO89] and [CoHC90] propose an approach based on explicit interfaces
and interface containment. In this system of object interfaces, one type
is considered a subtype of another if some subset of its interface is
identical to that of the second. [...] Hence in this system class-based
inheritance is strictly a reusability mechanism for sharing behaviour
between objects, not to be confused with subtyping. For example two
classes may be equivalent as types, though neither inherits anything
from the other. So class hierarchies are not the same as type
hierarchies, although they may overlap. Object interfaces [as in Java,
C++, etc. - Paul] clarify this distinction between interface containment
(subtyping) and class- based inheritance and give insight into
limitations caused by equating the notions of type and class in many
typed object-oriented programming languages [such as Simula 67 - Paul]."


http://progwww.vub.ac.be/prog/persons/kimmens/research/Introduction-to-OO.html

The paper itself is called: "Inheritance is not subtyping" and is quite
famous, but unfortunately predates the Web.


As Paul has pointed out, "class" is the looser term. The distinction which you
acknowledge between class and type in OOP also exhibits this difference in
objectivity and precision: a class is an essentially arbitrary collection of data
and (data processing) methods. "Type" bespeaks the detached observation of a
common characteristic. If the definition of that common characteristic is
narrowed, certain examples which formerly met the criteria of that type will no
longer, and will clearly have no place in a grouping of that type. With class, in
C/S as in society, the criteria for inclusion are idiosyncratic and inconsistent.
We can conclude only that a member may arguably belong to a class on the evidence
of that member being included in at least one taxonomist's specification of that
class.

That said, the imprecise articulation of these two terms in discussion of the XML
standard and its dependents reasonably mirrors the workable, if still inchoate,
guidance which the standard offers, right now, for accomplishing useful work.
Clearly the present standard will not support a useful mechanism of class
inheritance. Yes, the reason it will not is rooted in imprecise definitions.
Forget it for a while. There is plenty other work we can base on the existing
standard right now.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)




More information about the Xml-dev mailing list