xml-dev - Re: Inheritance/defaulting of attributes

[Paul Prescod <papresco@technologist.com>]

Martin Bryan wrote:
> 
> Firstly let me pick up on the name question. Because of the 
> preconceived ideas that programmers have about what inheritance 
> and subclassing involvesI would love to get away from these terms.  

There are costs to forging a new terminological way. I would like to
think that the mechanism I have described will seem familiar to OO
programmers as the logical generic markup versions of the concepts of
subclassing and inheritance. This will help them learn about it. But
then it is *my* proposal so I would say that.

> I really liked the term
> >Environmental Acquisition
> defined in
> > http://www.cs.technion.ac.il/~david/Papers/Tech_Reports/lpcr9507.PS.gz
> >in:
> > http://www.cs.technion.ac.il/~david/publications.html
> >
> This fits in beautifully with SGML as it incorporates the concept of being
> able to use context to determine the meaning of elements, which is one of
> the great plusses of SGML. This fits in nicely with what has been done in
> HyTime and DSSSL to allow querying of context within groves.

Environmental acquisition is *only* about context-based inheritance, and
not at all about subclassing or class-based inheritance. It is about
"runtime" and not "compile time". So I think that it is a separate
concern.

> The one area of concern I have with your proposal is over the position of
> INHERITS. Unlike the other keywords you have proposed this defines the
> attributes to be associated with the following named parent rather than a
> mapping to be applied  to the following element name. I would like,
> therefore, to distinguish this fact by placing it after the model group
> rather than before it. e.g.
> <!ELEMENT area  EMPTY INHERITS (sizeable, has-href)>
> This would have the advantage that you could then combine TYPEOF and
> inherits:
> <!ELEMENT dog TYPEOF animal (puppies+) INHERITS (pedigree, kept-by)>

This seems like an excellent proposal. I will incorporate it in my next
version.

> >Since archforms do not have parser level subclassing, the parser cannot
> check subclasses for conformance as OO language parsers do. Nor can
> DTDs be checked for conformance to meta-DTDs.
> 
> Again why presume it has to be done by a single parser? There may be good
> reasons for keeping these separate.

I guess I don't care if it is one processor or six, but I want the
semantics of subclassing and inheritance to be checked in the DTD, and
not only in instances. Since the SGML parser is often the only processor
that has access to the DTD, it is the logical place to check it.
 
> This is the key - architectural forms are not subclasses, they are ways of
> identifying that processing relevant for a known class of objects are also
> relevent for this new class of object.  They are about reusing existing
> knowledge/coding rather than about inheriting properties per se. 

Careful there! I think that you are using subclassing and inheritance
interchangably. Subclassing is always about reusing existing
knowledge/coding. What I am proposing is merely that you should be able
to reuse knowledge/coding at every level -- including the SGML
validation level. Archforms allow this reuse only at the application
level (which makes sense considering that they did not have the option
of changing SGML).

> This is the
> problem with using terms such as subclassing and inheritence to describe
> them. What architectural forms are about is Environmental Acquisition.

Not quite. Although they do preserve the EA concept of "context" (when
they are used with LINK), they actually allow an element's
(architectural) class to be determined based on context. This is not
something I have ever encountered in any programming language.

 Paul Prescod

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