Inheritance in XML

[Robin Cover]

> Re: Subject: Re: Inheritance in XML (was Re: Problems parsing XML)
> Date: Sat, 18 Apr 1998 08:49:07 +0100
> Reply-To: "Martin Bryan" <mtbryan at sgml.u-net.com>

>>What is missing is that we can't define one class (element type) as a
>>subtype of another.

> In SGML you can use exclusions to make an element a true subclass of
> another:
> 
> <!ELEMENT X  (%Y-contents;) -(a|b|c)>
>
> providing a, b and c are optional components within the model for Y.
> Unfortunately XML dropped this useful option from the set of SGML facilities
> it in inherited
> 
> Martin Bryan

Martin, I wish I could believe this were true and useful.  It seems
that we confront here one of the several troublesome mismatches
between OO database modeling and SGML/XML markup, with respect to
the simple analogy:

OODB           SGML/XML Markup

class defn     element declaration
class name     element type
object         element
attribute      attribute

If we accept this crude analogy, and accept SGML's notion of an
"attribute" as a name-value pair, then the hope of creating subclasses
through SGML/XML element declarations appears slim.  Appears "to me" I
should say: I would welcome comments from the experts.

For starters, subclassing normally would mean further specialization
by the addition (possibly 'plus subtraction') of properties, viz., of
attributes.  Formally, then, an SGML element declaration can't do the
work: it would need to be an ATTLIST declaration.  But then we face
the problem that you can't model a complex attribute with the SGML
'attribute' anyway (if you want any validation): the "value" in
'(name-)value' is a flat/string in SGML, at least in the literal sense.

Of course, one can (and we all do) model "real" attributes using SGML
elements -- since we have no realistic alternative -- but that creates
other problems for the notion of using SGML element decls as a
subclassing mechanism.  One such problem is that (real) attributes are
unordered.  The straightforward way to model an object/element with
(some optional, some required) attributes a, b, c, d, e, and f would
seem to be: (a* & b? & c? & d & e?), but SGML/XML notions of
prescribing order in the serialization are fairly strong, and XML
won't even allow the use of the AND connector to indicate what I
plainly mean in this sample assertion. (Perhaps Steph Tryphonas has
written a program by now to convert all content models using AND to
use only OR, without sacrificing any integrity constraints on
occurrence and sequence).  In any case, the impulse toward
serialization in SGML -- at least in practice, given tools that force
end users to reckon with (arbitrary non-intuitive) "order" based upon
sequence rules in content models -- tends to work against the easy use
of SGML elements to model attributes.

Even apart from these mismatches between "object" modelling
and SGML/XML encoding, I question whether

  " <!ELEMENT X  (%Y-contents;) -(a|b|c)> "

creates a useful "true subclass."  Why would one want to create a
subclass based upon the subtraction of optional "attributes"
(subelements)?  I think that would make it a superclass in many OO
systems.  In this connection, one might be inclined to argue that the
treatment of "content" as a special attribute is unfortunate, at least
from the perspective of data modelling, where "part-whole" has no
quintessential role vis-a-vis "is-a" or "has-a" or "kind-of" or
"points-to"...  At which point, others would quickly point out that
they think it's specious to be talking about object modeling in terms
of SGML-based markup languages anyway, since "these languages can
neither formally express nor enforce semantic integrity constraints
which are so critical to good object modelling..."

I think this all leads me in the direction of favoring the efforts
at defining other schema languages (beyond SGML/XML DTD syntax),
granting that the validation of instances against their schemas,
if/when critical, will need to be done outside the framework of
the SGML/XML "parser/processor" as defined.  I have little doubt
that someone as brilliant as Eliot can show how the desired
objectives might be met through architecture processing by an
appropriate architecture engine; I don't know whether this is the
"best" path in all cases, or whether SGML/XML users will want to
deal with all the layers of indirection that architectures seem to
want.

I hope that experts with some years of experience in OO systems
will contribute their insights to the new "schema" projects.

-rcc

-------------------------------------------------------------------------
Robin Cover                    Email: robin at acadcomp.sil.org
6634 Sarah Drive           
Dallas, TX  75236  USA          >>> The SGML/XML Web Page <<<
Tel: +1 (972) 296-1783 (h)     http://www.sil.org/sgml/sgml.html
Tel: +1 (972) 708-7346 (w)
FAX: +1 (972) 708-7380
=========================================================================

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)