I want to go on record to state clearly and unambiguously that I have _no_
intention of having MIME support full SGML. First, SGML has its own notion
of the encoding of characters in which it regards the encoding as a number,
and binds the number to a character in the SGML declaration. The active
translation that some mail gateways perform on character encoding is
anathema to SGML's character set description. This means that the SGML
declaration may be transmitted as ordinary text, but the rest of the SGML
document must be transmitted as a binary object. Further, SGML has a
notion of "entities", or named collections of characters, and moving an
entirey entity structure by mail has not been specified or even attempted,
yet. (Various ad-hoc attempts notwithstanding.)
Full SGML _is_ complex, and Internet mail is not quite strong enough to
carry any random SGML document for several reasons, the above just being
the most visible ones. MIME could help us, but then MIME and SGML would
interfere with each other's domains because they describe the same things
and each would attempt to say that "this is binary", and "this is a GIF
image", and building the fully conformant SGML document from such pieces is
non-trivial.
If there be a general mechanism to transport SGML with MIME, it must be
specified by a separate RFC and use the general mechanism in MIME to
declare new content types. I'm not _opposed_ to this idea, but it's highly
premature to want to standardize it at this point.
What I want is just an SGML application that we define within the scope of
Internet mail and MIME and which works without installing a whole SGML
system. Although it would be "neat", it's overkill to standardize on SGML.
MIME itself can be mapped into SGML fairly simply, and so can RFC 822. In
fact, I do just that on an experimental basis right now with 35+ MB of mail
to play with. This doesn't mean that the two can happily coincide unless
one is clearly a subtype (notation) of the other. I want to have a MIME
subtype for structured text with typographical information complete. SGML
can handle that job very well, and an SGML application can be defined with
relative ease. However, it would be conceptually very different from
richtext, and that's the biggest hurdle.
Unfortunately, it's impossible to just add a DTD to richtext to make it
conform to SGML. Subtle, but important points make this very hard to
accomplish, such as small syntactic incompatibilities, a different
processing model, and the character set stuff. Not that SGML is a panacea,
but these differences result from just plain bad design on the part of
richtext, and a desire to over-simplify the problem. This is why I
so adamantly insist that we must take a serious look at this thing, not
just let it slide as an add-on to something else. Text markup is not in
the same ball park as programming languages and mail headers, and we need
to take cognizance of that fact.
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