james anderson mecom-gmbh at
Mon Nov 24 18:23:16 GMT 1997


sorry to start in the middle of this thread, but as an xml novice i'm
wondering why one is at all concerned to extend a language intended to
mark up "structure" in order to encode "behaviour". (this being the
distinction made by  separating 'class' and 'type').

why is it not sufficient to accept that an <!ELEMENT ...> dtd form
encodes the structure of one class only, and to encode the type and/or
class relations in marked-up data, instead of adding new elements to the
definition language? (eg ELEMTYPE).

for example
would encode the same information. what advantage do the special forms
and the additional processing mechanisms offer?

why, for instances, isn't the generic dt-element definition
 <TYPE>a type</TYPE>
 <MODEL>a model</MODEL>
? why does there need to be a BNF for document type definitions?

granted, i have gathered only that sgml background which i need to
vaguely understand XML's origins, but, in the processing of writing an
XML 'processor', i couldn't help but wonder why or whether all the
special forms are required by anything other than historical
(in point of fact, since it's possible to structure processors which
transform  all forms to a uniform intermediate representation, i doubt
that the syntactic distinctions are necessary.)

which brings me to ask why one would want to add more. for whatever

and, in passing, where it is noted
>And subclassing implies implementation-inheritance (i.e. code reuse),
>exactly what you were trying to avoid implying.
be careful not to conflate subclassing, through "implementation
inheritance", with code reuse. that applies only in languages which
identify class/structure-implementation with
behaviour-implementation. for a 'generic-function' language (eg. CLOS,
DYLAN) specifications for code reuse are in terms of the type relations,
not the class relations.

james anderson,

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list