Inheritance in XML [^*]

Thu Apr 23 21:20:56 BST 1998

james anderson wrote:
> 
> 
> where the property may concern type or it may concern class. that is,
> with respect to a given processing and storage model the respective properties
> may concern which operations may be be performed on the respective instances
> (read "subtyping") or they may concern what storage relationships the
> respective instances entail (read "subclassing").  

What do you mean by storage relationships (and thus classes) in the
context of XML?

> these are two, in principle, independant properties, each of 
> which may be inherited.

What are two properties? Type and class? Did you shift from discussing
properties "concerning" type and class and type and class *as* properties.

Can you also please defend the distinction between type and class? It
makes sense in object oriented programming languages (mostly for
performance reasons), but I don't know that there is any such distinction
in common usage or in most ontologies. I am prepared to be convinced
otherwise, but I think that the class/type distinction is specific to OOP
and is not useful except as an arbitrary distinction, to avoid confusion,
as it is used in the DSSSL spec. (node class, flow object class vs.
element type ... you could as easily reverse them and talk of element
classes and node types...)

> this comes to light, for instance in the assertion elsewhere in this thread,
> that architectural forms have nothing to do with inheritance. it is true, that
> they have only halfway to do with "class inheritance" - that is the storage
> structure implied by asserting that a given element conforms to one or more
> architectural forms. ( i think i claimed, in an earlier post, that they
> "punted" on this one. i still think that's true.) on the otherhand, they have
> everything to do with "type inheritance". that is, by virtue of asserting a
> relation between a concrete element and an archtectural element, certain
> operations which lead to a "valid" document state for the architectural
> element are produce the same state for the given concrete element. 

This is too abstract for me to follow. I don't think tha architectural
forms assert a relation between a concrete element and an architectural
element. Rather, I feel that they assert conformance, after a
transformation, of an element to an architectural element *type*.

You confuse me again when you talk about "operations" leading to a "valid
document state." I would appreciate it if you could expand on that.

> this is one form of inheritance.

It is true that an architectural client element inherits semantics from an
architectural element. As I have said before, the word inherit is very
vague, despite your relatively precise definition. The problem is that the
word "property" is very vague. For instance, according to that definition,
this DTD "inherits" from HTML:

<!DOCTYPE MYDTD [
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Strict//EN">
%HTML;
<!ELEMENT MYDTD - - (#PCDATA)>
]>

because it inherits the has-img-element property from HTML. 

> that given, if one claims - and is satisfied, that xml has by intention no
> sematic, and does not recognize that (without concern for an "application
> semantics") it is essential to provide at least a "dom semantics", then any
> discussions concerning serialized representations regarding assertions about
> types, classes, and inheritance (ie "schemas") will be ungrounded and bound to
> be futile.

XML has semantics on at least four levels:

First, XML documents have well-defined semantics as SGML documents.

Second, the XML spec. specifies many behaviours for processors.

Third, whether the XML spec. enforces it or not (and we could argue about
that), everyone who reads and understand the XML spec. comes away from it
with a similar understanding of its type system (such as it is). We
*could* pretend that that type system is just a mechanism for specifying
syntax (though I think that this is disingenuous), just as we could
pretend that Rosebud is a sled and Animal Farm is a children's story about
animals.

Fourth, at least four specs. depend on XML's "non-existent" semantics. If
they are to become RECs, someone will have to specify these semantics
explicitly, or admit that they already exist.

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

"Perpetually obsolescing and thus losing all data and programs every 10
years (the current pattern) is no way to run an information economy or
a civilization." - Stewart Brand, founder of the Whole Earth Catalog
http://www.wired.com/news/news/culture/story/10124.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)