-----------------------------
Application message id: 03446151211991/7947 X400
Grade of Delivery: Normal
-----------------------------
VMSmail To information: MUVAXA::MRGATE::"mci
_mta::*emsinternet::*mbx1ietf-822(a)dimacs.rutgers.edu::su=822
_extensions"
Sender's personal name: John C Klensin
Nathaniel Bornstein writes on Fri, 13 Dec 1991 09:25:04 -0500
(EST), responding to Guido van Rossum(_at_)cwi(_dot_)nl(_dot_)(_dot_)(_dot_)
- Has anyone consulted an SGML expert about this? I seem to recall
that SGML prefers to use tags with *semantic* meaning (e.g.,
<emphasis>) rather than *lay-out* meaning such as <Bold>).
I think that the word "prefer" here may be a little strong?
Actually, the word "prefer" is a little mild. The whole
concept behind SGML is to move things up to semantic (they call
them "generic" for a reason) tags, and most SGML experts would
use terminology like "abomination" for <Bold>.
At the point that one goes to low-level formatting tags, the
purpose of SGML is lost, and all one has is an overly complex
syntax.
- The <ISO-10646> tag worries me. I seem to recall that 10646 may
come in 2-byte and 4-byte flavors. How am I supposed to find the
corresponding end tag?!?!?! Or us some encoding scheme implied?
I'm not sure what the right answer to this one is. Any suggestions?
Noting that any use of 10646 is incompatible with SGML as I
read the standard (violation, not just extremely bad taste), and
all of the unpleasant experiences bound to what Guido so
politely describes with "may come", the right answer is to
remove all discussion of 10646 from the RFC except insofar as
absolutely needed to hold things together. And, even then, only
minimal placeholders should be included. Keep in mind, too,
that it is not possible to do an implementation that includes IS
10646, since there is no IS 10646.
If we understand how to make this work in ASCII or near-ASCII,
let's specify that and leave speculation about 10646 to
something at an appropriate future time.
Nathaniel then wrote on Fri, 13 Dec 1991 12:58:06:
Perhaps the real mistake is simply the use of multi-octet
character sets within the richtext framework?
No, the real mistake is trying to write a specification about
how to use something that hasn't been specified yet.
Multi-octet character sets within the richtext framework (or the
822/XXXX context generally) are just a corollary.
--john