Actually Richtext isn't that far off SGML now, although it would *really*
help if special characters such as <nl> for newline (or is it lt? sorry)
wer represented in some other way, e.g. @<lt> or @lt; instead. The SGML
Reference Concrete Syntax uses "&" unfortunately -- I am not going to
suggest that < be used, as then every other use of & would need to be
This distinction between notation for special characters and actual
tags/elements is, of course, one of the key differences between current
Richtext and SGML-as-one-would-like-to-use-it. And I would make a case
for "<" (as Erik has): anything one uses is going to need quoting if
others occur and, to take the alternate example you use just as an
example, "@" is used so much in the context of email addresses in
mail--text that talks about them, gives the addresses of others, sigs,
etc.--that I'd imagine it appears much more often than "&". And the
contexts in which it appears are those that would *really* confuse the
naive if it were quoted.
1]there should -- or could -- be a MIME subtype for transmitting SGML
documents. In this case, one would presumably transmit first the document
instance, then the SGML declaration (optional) and the DTD, and then the
...
Given the discussions of a year ago, this is an obvious candidate for
an application subtype that specifies the order and structure of things.
I think that doesn't require any interaction with the draft MIME doc at
all; it should just be a matter of documenting the conventions and
making a registration.
2]It would help if there were at least a couple of DTDs registered, so that
people sending SGML mail would not _always_ need to transmit the DTD.
I suspect that the AAP DTD -- although I don't personally like it, it
This is more interesting, since there are at least two possible ways
to approach it. One would be to have application/sgml for case 1 above
and either application/sgml-foo (where foo is a registered DTD name) or
application/sgml with some parameters of the DTD=foo persuasion and
a rule that including these parameters implied omitting the otherwise
relevant body [sub]parts for the second. A different approach might be
to use a tricky form of external reference to specify where one could
find the DTD if needed but use a sufficiently reserved identifier that
one could know *not* to bother retrieving it in most cases.
Those alternatives in model, while not earthshaking, are probably worth
a bit of WG discussion to decide what precedents we want to set rather
than having accidents happen on the basis of who gets to IANA first.
john