[Marc Andreessen]
:
| You labeled the creation of such a language "an exercise in futility".
No, I didn't. I labeled the exercise of doing so under the _size
constraint_ "of similar size (definition and code)" as futile. Indeed it
is: richtext in RFC 1341 is a declaration of intent, not a specification.
A specification will of necessity be much larger. It doesn't need to be
more _complex_, but it need to fill in all the holes and assumptions that
need to be filled by the implementer today. I found it impossible to
implement richtext without access to the ietf-822 archives. We can't wrap
the multiple megabytes of archives into an appendix and say "read this to
figure out what we meant, but didn't tell you explicitly".
| Once again, if carrying out out this task is indeed futile, how can
| SGML possibly be seriously proposed as a viable structure for creating
| document description languages?
Gimme a break. If you have an axe to grind, feel free to mail me. I'm
sure I can give you a lot of ammunition against the project leaders and/or
software vendors that have caused you to unfairly blame SGML. Similar
attitudes were paraded on the list by someone who said that SGML requires
"thousands of lines" of preamble to be useful, and that's pure bullshit,
too. I frankly don't understand why people are so antagonistic towards
SGML, except that it does formalize a model that some people are mortally
afraid to deal with. I didn't expect to find such people on this list, and
I hope I haven't.
SGML requires more specification because it requests that you formalize
your decisions. Handwaving and sufficient access to the oral tradition
and/or the mailboxes of the authors of a bad spec will accomplish the same
thing, but not necessarily as well, or as fast, and the resulting actual
format will differ as much as that of USENET news differs from RFC 1036.
I'd hate to see as many richtext versions as isolated development teams
deciding what things "meant". That's why we need more attention to detail,
more discussion of semantics, more discussion of the processing model, and
more specifications. You may associate all of these activities with PHIGS
if you like, but I'd like to point out that richtext received less than 1%
of the mailing list volume on ietf-822, and I request that we give the same
level of attention, if not more since it's a new thing for us, to richtext
or a son-of-richtext.
You come across as telling me that the less we specify, the better, and the
less rigor applied to specifications, and the less troublesome discussion
we engage in prior to putting our handwaving in print, the more "useful"
things will be. It's this fundamentally anti-specification attitude that I
find so objectionably as to make me sick.
Fortunately, and I mean that quite seriously, I learned how standards
should look from early RFC's, and I've brought that with me to my ISO work.
Of all the bloated ISO standards that I have worked with, I find that SGML
is a simple and concise thing. There's only so much you can force into 58
pages of requirements. Take a look at ODA, MHS (X.400), etc, and you'll
find that they spend as many pages on the ASN.1 code for each of their
multiple parts. That's what I consider to be wasteful, and I'd join ranks
with you in flaming such overspecification, but I'd also keep a level head
and avoid falling into the trap of thinking that all good specifications
are necessarily over-specified. They aren't. RFC's are sometimes under-
specified, and this _has_ cost developers quite a number of grey hairs.
However, none of them have been as vague as richtext is. (Indeed, I'm
unhappy with all of RFC 1341 for this reason. RFC 822 is rigorous in
comparison.)
| No, but when I see the same mentality, seemingly inclined towards
| complexity for its own sake and dismissing the idea of creating
| reasonably simple and workable systems as "futile", I start to wonder.
OK, now you're making me real pissed, Marc. Go back and read what I wrote
about "make it simple, as simple as possible, but not simpler". I argue
_against_ over-simplification, and I'm quite irate for your twisting that
into being "inclined towards complexity for its own sake". If you can't
keep those two viewpoints apart, it's not my fault.
| I'm not just SGML-bashing; I was looking forward to (and continue to
| look forward to) seeing the "real SGML" equivalent of richtext -- even
| just as a case study of how SGML is indeed a workable system -- and
| because of this I am disappointed that you don't think it's worth your
| time to create it.
I hope this message has made it clear to you that I was arguing against
comparing simplicity of specifications by their size of definition, and
that getting something useful done with a handwaving, sub-minimalist
declaration of intent for a specification and a snippet of code to _remove_
richtext for an implementation is not my way of doing things, nor a way
that the Internet tradition has previously engaged in, either. Look at RFC
822 and RFC 821. They are _quite_ complex things, if you want to follow
them faithfully and make a correct implementation. I see no point in going
below that level of complexity, and I think a lot of useful stuff can be
specified at that level. richtext, however, is a specification vacuum in
comparison. _That_ is what I'm arguing against. See?
BTW, I'd prefer to see a major face-lift operation on all of MIME for the
Draft Standard level RFC, but that's probably completely unlikely to happen.
Best regards,
</Erik>
--
Erik Naggum ISO 8879 SGML +47 295 0313
Oslo, Norway ISO 10744 HyTime Watch this ^ space
<erik(_at_)naggum(_dot_)no> ISO 9899 C Memento,
terrigena
<SGML(_at_)ifi(_dot_)uio(_dot_)no> ISO 10646 UCS Memento,
vita brevis