Erik,
I've implemented richtext and I agree it has some serious shortcomings. I'm
personally compiling a list of concrete suggestions to insert into the
discussion (or forward to the RFC authors) at an appropriate time.
A lot of your criticism about richtext seems to be "it's not SGML".
If the fact that richtext resembles SGML causes problems in the SGML camp,
then perhaps we should change richtext so that it *does not* resemble SGML,
or at least drop any claim of SGML compatibility in the richtext definition.
Alternatively, if we can "tweak" the existing definition so that it is more
compatible with SGML, that's a good thing to do -- particularly if it allows
us to define "enhanced richtext" that has more features but can still be
parsed with a simple richtext reader.
I have no doubt that SGML experts and others who are more familiar with
document representation could add some valuable input to this re-definition
process, however...
I don't know SGML. I know "C". I don't want to have to learn much about
SGML to write a richtext interpreter. I want a spec that defines what
*richtext* commands look like, how they nest, what their semantics are, and
how to extend the command set in a way that doesn't break things. I want it
be *easy* to implement, because I want every MIME implementation to support
it. If the language defined by the richtext spec is SGML-based, fine, but I
don't want to have to deal with it on that level.
Perhaps you, as an SGML expert, would care to produce a simple definition
(or even a concrete example) for a richtext-like language which is of
similar size (definition and code) and capability as the current richtext,
and which is SGML compatible, but which doesn't require extensive knowledge
of SGML to understand or implement? Then perhaps I and others could see
what kinds of changes you are proposing.
Keith