Proposal for src files

[W. Eliot Kimber]

At 07:29 PM 4/2/98 +0200, Matthew Gertner wrote:
>Eliot,
>
>You make a lot of valid points, but I can't held feeling that your stance is
>a bit radical. The fact of the matter is, I asked myself the other day
>exactly how HyTime handles inheritance and spent at least an hour trying to
>find the answer. Of course, I wasn't entirely sure that I understood at the
>time and I certainly couldn't explain it to you now without looking it up
>again. And this despite a pretty solid grip on SGML and OO technologies, as
>well as a thick stack of SGML-related bookmarks in my browser.

That's probably because the architecture facility of ISO/IEC 10744 doesn't
*do* inheritance in the way that most people seem to expect. It lets you
define hierarchies of semantic derivation, that is "this element is derived
from type X defined by architecture Y". It provides a way to validate
elements derived from type X against the DTD rules defined by architecture
Y. But that's it. It's completely passive and declarative.

Architectures *enable* the combination of elements derived from various
sources, but the act of combining is done by the human that defines the
resulting document. There is no automatic process, nor, as far as I can
see, can there be in any generally useful and non-trivial way.

It is fruitless to try to draw too many analogies between SGML
architectures and object-oriented programming because they are different
kinds of things.  Architectures are purely about data definition, OO is
about active programming.

I'm not sure this makes the issue any clearer, except to say that you
cannot understand architectures in terms of object-oriented programming.
Architectures are *much* simpler than that: it's purely a mapping from
elements in a document to element types defined in a separate
specification.  *All* the machinery defined in the AFDR annex is about
enabling SGML validation of the result of resolving the mapping and
providing syntax shortcuts for defining the mapping. But at its heart, it's
just a simple syntactic mechanism for mapping from instances to schemas
(architecture definitions). Nothing more, nothing less.

But even this simple facility has profound implications and significant
potential benefit in terms of making document type definitions managable,
scalable, and re-usable.  

Any work done at the schema definition level (that is, the non-DTD syntax
used to define schemas) is gravy. If these extensions include more truly
object-oriented stuff, so much the better (I think--I'm actually highly
skeptical of the true benefit of object-orientation).  

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
Highland Consulting, a division of ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202.  214.953.0004
www.isogen.com
</Address>

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)