Papers in PDF format

In this case, the Los Alamos National Laboratory's Advanced Computing Laboratory has concocted a highly specialized
type of conference announcement that permits extensive automated processing by Web clients throughout Los Alamos.
However, should someone at MIT be looking at the conference announcement, his Web client would fail to recognize
the type and look at the field. As
is a superclass of , all the things that the
MIT user's client is accustomed to doing with conference announcements should work with this one.
Nonhierarchical inheritance (also known as "multiple inheritance") is also important so that duplicate type hierarchies
are not spawned. For example, the fact that a document is restricted to a group or company might possibly apply to any
type of document. Should there be two identical trees, one rooted at and the other at
? Then we might imagine documents for which there is an access charge. Now we just
need four identical trees, rooted at
. There is a better way and it was
demonstrated in the MIT Lisp Machine Flavor system (a Smalltalk-inspired object system grafted onto Lisp around
1978): mixins. Mixins are orthogonal classes that can be combined in any order and with any of the classes in the
standard kind-of hierarchy. Here are some example mixin classes:
Class Name Fields Contributed Comments
(explains who can access, possibly a domain name or list
of networks)
User Agent displays
"****DRAFT****"
prominently, offers to look
up previous version and
show change bars.
HTTP server watches for
documents whose type
inherits from this class and
only delivers them to
authorized users;
non-authorized users sent
an explanation with the
name of a person who
could authorize release.
If there are N mixins recognized in the public type registry, we might have to have 2^N classes for every class in the old
kind-of hierarchy. That's one for every possible subset of mixins, so we'd have classes like
,
etc. This doesn't seem like a great improvement on the 2^N identical trees situation.
However, if we allow documents to specify multiple types
and build the final composite type at runtime in the content editor, HTTP server, and Web user agent, then we need only
have one hierarchy plus a collection of independent orthogonal mixins. This presents no problem for programmers using
modern computer languages such as Smalltalk and Common Lisp. These allow new type definitions at run-time and
have had multiple inheritance for over a decade. A program implemented in a language that has purely static types, e.g,
C++ or Java, is going to need to include its own dynamic type system, built from scratch and not based on the
underlying language's type system.
We established then that we need multiple inheritance and distributed extensibility. A standard Internet approach to
distributed maintenance of a hierarchy is found in the Domain Name System (DNS), where authority for a zone is
parcelled out and that authority includes the ability to parcel out subzones [Stevens 1994; Mockapetris 1987a ;