Inheritance (was: Access Languages are Tied to Schemas)

Paul Prescod (papresco@technologist.com)
Fri, 21 Nov 1997 13:09:22 -0500

Rick Jelliffe wrote:
> The best idea I have some up with is the following: to allow a new keyword
> #OTHER (or #ANY)
> to be allowed in content models, to represent any one unambiguous element type.
> This allows the creator of the original content model the ability to
> declare points in content models which are publically available for extension
> by derived element types (declared or undeclared).
>
> I currently think that any inheritance-based declaration system must presuppose
> such explicit inheritance points. I think it is merely a matter of strong typing
> and interface control.

Strong typing and interface control are issues of subclassing, not
inheritance. Inheritance is just a code reuse mechanism. Unlike
subclassing, it does not allow more expressive DTDs to be created (which
is, presuamably, what you are talking about). I think that we must keep
these ideas separate in our mind if we are to make progress on either
front. Their conflation is, (IMO) just a historical mistake driven by
early compiler limitations and performance considerations that do not
apply to SGML. Both concepts are useful in SGML, but they should be
separate, just as they are in most modern OO programming languages (C++,
Java, CLOS, Python, etc.), even those which conflate them in the syntax.

I described the difference in:
http://www.lists.ic.ac.uk/hypermail/xml-dev/9710/0077.html

Anyhow, you can emulate OTHER using subclassing without a first class
OTHER construct.

<!ELEMENT CITATION (name, author, date, OTHER-CIT* )>
<!ELEMCLASS OTHER-CIT> <!-- no constraints on subclasses -->

<!ELEMENT URL (#PCDATA) SUBCLASSES OTHER-CIT>

Now URLs can go in CITATONS after the date.

Paul Prescod