To: moore(_at_)CS(_dot_)UTK(_dot_)EDU
cc: lee(_at_)SQLEE(_dot_)SQ(_dot_)COM, enag(_at_)IFI(_dot_)UIO(_dot_)NO,
NED(_at_)SIGURD(_dot_)INNOSOFT(_dot_)COM,
gvaudre(_at_)CNRI(_dot_)RESTON(_dot_)VA(_dot_)US,
ietf-822(_at_)DIMACS(_dot_)RUTGERS(_dot_)EDU
From: John C Klensin <KLENSIN(_at_)INFOODS(_dot_)MIT(_dot_)EDU>
Subject: Re: MIME to Draft Standard
Date: Thu, 21 Jan 1993 09:12:29 EST
From my point-of-view, I have a similar concern -- I want to be able to
extend the set of richtext commands that do not nest (and thus do not
require a matching "end command"), and to be able to tell by looking that a
particular command is non-nesting. (Such commands, in my view, might not be
Keith,
Thinking about this from an SGML perspective, there is an important
distinction. Rather than try to explain the details right now and bore
people to death, what do you mean by "non-nesting"? Is the issue that
there are some things that inherently don't need end-tags, so you want
to leave those out?
Yes.
At present richtext lets you define your own commands, which will be
treated as no-ops on a viewer that doesn't support them...but they
have to have matching end-tags, and this is sometimes inappropriate.
So I'd like a richtext parser to be able to determine from syntax,
that no end-tag is expected for a particular command.
Keith