We have no major SGML user community here. However, everybody I've
shown RichText to has gone into "wow mode" and thinks it's pretty neat.
Can somebody please itemize the problems in RichText as currently
defined which cause problems with these "existing tools and compatability"?
I second this. I use SGML all the time, but I use a particular instance of
it only and I don't know the general rules.
What is in RichText that can't wait for a revision document, and that will
horribly break all existing RichText viewers because it's not at all
backward combatable?
Agreed.
Unless somebody can produce a *real* show-stopper, I am tempted to say
that our site is *at present* satisfied with RichText *as is*, and that
the problems should be addressed in a year or two in a "Return of RichText"
document. Yes, RichText isn't fully SGML-compatable, and yes, there's
still warts on it. However, from what I've seen, it gets the job done.
Agreed. And I also agree with Nathaniel -- we urgently need to have some
form of "enhanced text" as part of the base MIME document. This is an essential
feature, not so much because people won't use such things otherwise, but
instead because people will be tempted to use an incredible spectrum of
different things if there isn't a well-defined format available at the base. If
everyone uses something different we will have nothing but interoperability
problems.
I think the pent-up demand for something like RichText is enormous. I suspect
that it end up being one of the most important and most heavily used aspects
of MIME. (This won't happen immediately, but I think it will happen.) This
makes specification of some format essential.
Let's reach closure and get this sucker out the door - I think we *need*
to get this out in the field so we can get a clear idea of what the
*real* problems are. I'll bet a large pizza(*) that a year from now, we will
be looking at it and realizing that the *real* warts in RichText are
something totally different than what we're arguing now.
Again, I agree completely. I see the probable source of significant trouble
in RichText as being somewhere in the feature set it chooses to offer. I cannot
see that the syntax is at all important -- it is only the sugar coating on
the pill.
If there are syntactic differences between SGML and RichText I cannot see how
it would be anything other than trivial to fix them with a simple converter.
(If someone can prove me wrong on this I'd like to hear the specifics.)
I realize that there are some semantic differences between RichText and SGML.
Actually, I guess that they are more stylistic differences, since SGML
does not specify semantics, but it does give an idea of what sorts of tags you
should have. RichText tends to get down and specify appearances of things,
whereas SGML tends to be more abstract. I recognize this for what it is -- an
essential conflict between the notion of an abstract markup language and a
language that is intended to describe a simple display format. I'm sorry, but
when I write mail I don't think in terms of <emphasis> and <footnote> and
<quote> and <abstract>. I think in terms of <bold> and <underline> and
<smaller> and <larger>. (And frankly, while I do agree with the general
principle of abstraction, there are times when it simply does not work, and
the inability to work around this in the SGML DTD I use really stinks.)
I guess the bottom line is that I don't see slight nonconformance to SGML
as the major issue. Rest assured there's a major issue in there somewhere,
but I don't think we'll ever find it until we implement a bunch of RichText
processors. If we send RichText back to committee we'll effectively block
the implementation efforts that are the only possible source of us really
knowing what we're talking about.
Ned