Inheritance/defaulting of attributes
mtbryan at sgml.u-net.com
Wed Oct 8 09:35:12 BST 1997
I really like your inheritance paper, but would like to suggest a minor
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
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
<!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
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 at sgml.u-net.com
For more information about The SGML Centre contact
For more information about the European Commission's
Open Information Interchange (OII) initiative contact
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev