"OO" Schemas (with examples!)

[Paul Prescod]

matt at veosystems.com wrote:
> 
> The exceptions, like C++'s private inheritance, are at
> the margins.  In what language that you are aware of does inheritance
> or subclassing not imply substitutability?

I've been thinking a little further:

I think that it is good to allow inheritance (attribute and content model
sharing) without substitutability (the ability to plug elements of one
type in for elements of another). But since inheritance is always a labour
saving device, I can just avoid it when I don't want substitutability.
This will encourage bad design in some cases (as it does in Java), but
that's okay, we could add "private inheritance" later, as you could in
Java.

To make this concrete, consider these statements:

<!ELEMENT A (EMPTY)>
<!ATTLIST A ATTR CDATA #IMPLIED>

<!ELEMENT B INHERITS-FROM A>

<!ELEMENT C (A)>

Questions:

Inheritance: Does B have an ATTR attribute?
Substitutability: Can a C contain a B? 

The answer to the former is probably "true" in a reasonable inheritance
system for XML types. B got a property (the existance of an attribute)
"for free" from A. This is a nice feature that eases maintenance and
reduces code duplication. The answer to the latter is more complicated. If
you say yes, then you are saying that inheritance implies
substittuability, like Java, but unlike C++, Smalltalk, etc. If you say
no, then you are saying that inheritance and substitutability are two
different features and are more or less unrelated, except that they often
work together.

I am saying that I prefer the second answer, but if the first answer wins
out then I can just avoid inheritance when I don't mean to imply
substitutability, and just declare the attributes twice. Similarly, in
Java I can build proxies to implement code reuse without inheritance. I
can live with that.

The really important thing is that substitutability should not require
inheritance. Note that Java (C++, Smalltalk, etc.) do not make this
mistake. In Java, substitutability can be defined with interfaces so that
no particular implementation is required or implied. This is just as
important for documents. We are very, very close to having a clear
language for describing substitutability, but we must not get distracted
by the (comparatively unimportant) issue of inheritance. Let's forget
about inheritance for a second, get substitutability right, and we can go
back and fiddle with code saving devices later! We must especially not
confuse the two! 

Consider, for example, an element that wants to be substitutable for an
HTML A element. Perhaps it is a special hypertext bibliography element
that gets its URL from a child element named URL:

<BIBLIO>
	<ISBN>...</ISBN>
	<PUBLISHER>...<PUBLISHER>
	<URL>http://....</URL>
</BIBLIO>

We can easily translate this to an A HREF element using XSL's
transformation language:

<A href="{URL}">
	<B><xsl:process select="ISBN"/></B>
	<I><xsl:process select="PUBLISHER"/></I>
</A>

Thus, this:

<BIBLIO>
	<ISBN>XXXXXX</ISBN>
	<PUBLISHER>Prentice Hall<PUBLISHER>
	<URL>http://....</URL>
</BIBLIO>

would become:

<A href="http://....">
	<B>XXXX</B>
	<I>Prentice Hall</I>
</A>

The implications of this for e-commerce and document interchange are be
clear. You can define these "substituability mappings" into schemas
created by other people, and just "plug in" elements named according to
your own vocabulary. You can even use a schema to verify that anything
that conforms to your vocabulary will come out of this mapping conforming
to the containing application's schema.

But note that I've done no "inheriting" here. My BIBLIO type got no
property from the A type. In fact, it may have been invented completely
independently. I can "impose" substitutability on a type from outside,
just as I can in an OO language with a "proxy." The XSL rule is my proxy.
I fear that these important features will get lost in the rush to
"inheritance".

So what I ask is that you recognize that a) substitutability without
inheritance is at least as important as in in Java, b) as long as you are
going to provide that, you might as well provide inheritance without
substituatability and c) we need advanced kinds of substitutability such
as the one described above.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

It's such a 
Bore
Being always
Poor
LANGSTON HUGHES
http://www.northshore.net/homepages/hope/engHughes.html



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)