Lists Home |
Date Index |
- From: firstname.lastname@example.org (David G. Durand)
- To: email@example.com
- Date: Thu, 9 Oct 1997 11:16:06 -0500
Tim's post reinforces the very correct point that "document
inheritance" is not very well defined. In my analysis of
"things we do in DTDs that are inheritance-like" I came up with at
least the folowing kinds of inheritance (I hope to work this into an
article at some point):
Content-model inheritance: sharing or extension of a content model
of one element with another element.
Content-model Context inheritance: sharing of a place of potential
occurrence in the content model(s) of (an)other element(s).
Attribute Inheritance: elements that inherit a particular attribute
Attribute List inheritance: elements that share packages of
attributes that go together. XML's separate attlist declarations will
make implementing this kind of inheritance with Parameter Entities a
Inter-Attribute List inheritance: multiple attlists that extend each
other, and apply to different elements.
Ontological inheritance: for things like P, P.BLURB,
P.EXPLANATORY. We sometimes have an organization of the elements into
a conceptual structure of types and sub types -- any of the other
kinds of things listed bere might (or might not) be inherited on the
basis of such relations.
Of course, these are really kinds of sharing that people implement
through PEs or hand expansion. They are not always arranged in a
hierarchical fashion, sometimes the elements in a DTD are just
partitioned by sharing of certain attributes. For instance an
architectural form like XML-LINK partitions elements into "link
elements" and "other elements", without any explict notion of
hierarchy of sub-typing. Of course, a DTD author's "ontological
hierarchy" may affect how such sharing is actually structured in the
Within an instance itself, we could also have inhertance -- that would
be really inhertance and not sharing, since people have poposed that
elements would inherit from their containing element. Things that have
been proposed here are:
Attribute Inheritance: Some attributes might acquire (default)
values based on what they are contained in (or its attributes).
Declaration Inheritance: Content models (or other DTD-declared
properties) might change depending on what an element is contained in.
This would enable elements like "name" to have different properties
depending on whether they are contained in a "bilbiography" or a
This is an area where there are a lot of bright ideas, but little
experience in practice. This could be the direction of the future for
My point in this is that we have (at least 5 distinct kinds of
property to share) as well as an ontological hierarchy (which might be
a rough equivalent to the real-world phenomena that underly O-O design
proceses). In fact, architectural forms offer the possbility of
multiple ontological hierarchies in the same DTD.
In the document instance, we have all the same kinds of inheritance
(which I bundled under declaration inheritance) plus "attribute value"
inheritance. The advantage of document instance inhertance, is that
the parent relationships are constained by the structure of the
instance, whereas DTD relationships are restrained by the cleverness
of the DTD author.
None of these have the properties of the objects that OO design
deals with, where we generally inherit field values, and functions
from one domain to another domain. This means that we don't have to
worry about covariant versus contravariant subtyping of methods, but
it also means that OO is not _especially_ more relevant that any other
knowledge description language. The properties we are inheriting are
very different, and the strategies to control them will probably be
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)