Dana and Erik,
My poor, overloaded mailbox would really appreciate not rehashing
the whole RT-vs-SGML issue (as distinct from clarifying any ambiguities
that appear with RT, which is where this discussion chain started).
Let me make two observations in the hope of clarifying what I think
(hope?) is the intent of Erik's comments. They also contain at least
some stuff that I don't think has been said before on the list...
(1) Implementations and DTDs aside, SGML is pretty established,
documented, and well-understood as a language. As a language, it has
some overall semantics, not just the specific syntax-semantic bindings
implied by particular DTDs. One of the advantages of this is that
questions about the meaning of various tag-nesting patterns are pretty
well understood and their answers are predictable. And the process of
working up DTDs involves a formalism that takes care of the rest and
does so at very high precision.
With RT, we've got to *do* all of that stuff somehow. The process of
just muddling through until someone notices that there are two different
ways to interpret something and then asks doesn't appeal very much, but
will probably work as long as we all look carefully for those things.
If we don't look, then there is the risk that different people will
interpret the constructions in different ways, contributing in a small
way to lack of interoperability. The SGML formalisms that permit
finding these little traps and force making choices about them have a
The other alternative, of course, is the "reference implementation"
approach, where some implementation is the *real* definition, rather
than anything in an RFC. I think we need to resist that approach.
(2) If one is faced with a certain document type and DTD to be
processed, there are two ways to "implement SGML". One involves
starting with a general SGML processor, binding the DTD to it, and
thereby processing the document. The other involves building a
DTD-specific processor starting, typically, with some sort of lexical
thing and a macro generator or other text diddler. With
appropriately-designed DTDs, some groups have had good success with
programmable editors of the emacs or TPU persuasion.
Where this is all leading is that the conceptual leap from "RT" to
"RT as a special SGML DTD" is not huge. There are some disadvantages to
taking that approach -- if one is going to use an SGML structure, some
ideas immediately suggest themselves about the nature of tagging, no one
has every claimed that DTDs are easy to write, and there would be some
merit in trying to figure out if an existing and heavily supported DTD
would be appropriate instead of "one of our own". But, if you suppose
we had done that, you would have two plausible implementation strategies
available for your Macs:
(i) Find an SGML processor and hook it up in an appropriate way. This
alternative would be unattractive if you couldn't figure out where to
(ii) Build *exactly* the same special-purpose tool for RT as specified
in a DTD that you would build for an RT with a standalone definition,
but with more confidence that some ambiguity of specification wasn't
waiting around to get you.