Inheritance/defaulting of attributes

[Paul Prescod]

Rick Jelliffe wrote:
> Editorial people have the idea of text replacement well and truly
> in their minds: it is what they do, and what they think they are
> doing when they do it.
> 
> So the PE mechanism, being akin to macros or text replacement,
> is very appropriate.  The ideas of inheritance and classing
> are not appropriate for editorial people for the same reason.

That isn't true. Anyone who can understand the concept of types and
instances can understand the concept of sub-types.
 
> Now XML is being much more targeted at database kind of systems,
> where the DTD designer is clearly more of a programmer.  

No, this push for subclassing and inheritance has nothing to do with a
re-targetting of SGML. Most major SGML DTDs (e.g. HTML, DocBook and TEI)
have nothing in particular to do with databases and yet they all include
a concept of subclassing and many use inheritance also. Anywhere you
have object types people will ask for object sub-types. SGML has element
types and thus people ask for element sub-types (or sub-classes).

I do not believe that "editorial types" find the parameter entity
hackery used in these DTDs to be "intuitive" because they are
comfortable with text substitution. A straightforward encoding of the
subtype relationships inherent in the information would be more
intuititive.

> It may
> be that such programmers cannot think in terms of text replacement
> or symbolic computing, but in terms of whatever the fashionable
> OOP and framework are at the time.  So it may be that they want
> a less text-based style of declarations.

As I said before, the concept of subtyping (or subclassing) predates OOP
by at least *2300 years*. It comes from Aristotle, not Stroustrop. The
programming languages community was bound to invent it for the same
reason that we are bound to do so -- wherever there are types, some
things will be better modelled with sub-types. Markup people would have
invented it first if we had the budgets of programming language research
groups.
 
> A push for OO constructs for element declarations actually creates
> a new distinction between declarations and the instance: the
> declarations would act by inheritance and magic and the document
> acts by text replacement: or is there some meaningful extension of
> inheritance to include instance data?

My proposal from yesterday does this.

<!ELEMENT animal EMPTY>
<!ELEMENT (shark|lion) ISA animal)

<!ELEMENT zoo (animal+)>

<ZOO>
<SHARK/>
<LION/>
</ZOO>
 
> Has anyone come up with a good solution for what order element
> types can be in if you have inheritance?
> 
> <!ELEMENT cat  (head, whiskers, paw+, tail)>
> <!ELEMENT kitty  (cry) INHERITS cat>
> 
> is all very well, but what is the resulting content model?

Well, this is inheritance which is different from subtyping. We can and
should be clear that there is a distinction and you don't need one to
have the other.

According to my model from yesterday, the content model above is (cry).
Just as in OOP, if you specify a property (in this case the content
model) it should override that property in the parent class. Since you
have not claimed (according to my straw person syntax) that kitty is a
subtype of cat, the above is legal, but non-sensical. Why would you
inherit a content model and then immediately override it?

> It sounds like people expect it to be (using the SGML "&"
> connector, which is not in XML):
> 
> <!ELEMENT kitty (( head, whiskers, paw+, tail ) & cry )>
> 
> which is not very satisfactory IMHO.

I don't see this interpretation as being very useful. If we want to
allow inheritance of portions of content models (which is dubious in my
mind) then this can be accomplished easily with new syntax.

<!ELEMENT cat ( head, whiskers, paw+, tail, $EXTRASTUFF )>
<!ELEMENT kitty INHERITS cat WITH $EXTRASTUFF=cry>

I don't know if the extra feature is worth the new syntax. Still if this
is determined to be a requirement, it can be easily solved.

 Paul Prescod

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;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)