xml-dev - Re: Inheritance/defaulting of attributes

["Martin Bryan" <mtbryan@sgml.u-net.com>]

 Paul

I really like your inheritance paper, but would like to suggest a minor
change.

Firstly let me pick up on the name question. Because of the preconceived
ideas that programmers have about what inheritance and subclassing involves
I would love to get away from these terms.  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.

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)>

>Architectural forms do not directly express the notion that element type
A ISA subclass of element type B at the SGML parser level.

Not at parser level, but at architectural processor level, where the
architectural processor could be a spawned SGML parser working from the
meta-DTD. Thats deliberate.

>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.

>More subtly, I don't think the true subclassing relationship finds any
direct expression in the archform concept at all. Rather archforms
allow you to express that individual elements of type A ARE-ALSO-OF
type B.

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. This is the
problem with using terms such as subclassing and inheritence to describe
them. What architectural forms are about is Environmental Acquisition.
-----------------------------------------------------------------

Martin Bryan, 29 Oldbury Orchard, Churchdown, Glos GL3 2PU, UK
Phone/Fax: +44 1452 714029 E-mail: mtbryan@sgml.u-net.com
For more information about The SGML Centre contact
http://www.sgml.u-net.com
For more information about the European Commission's
Open Information Interchange (OII) initiative contact
http://www.echo.lu/oii/en/oiistand.html




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)