[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Richtext and SGML (Was: MIME to Draft Standard)
Steve Summit writes, in part:
>Conceptually, RTF is similar to SGML in that there is a fairly
>general syntax which delimits various types of entities. The
>problem is that the semantics of too many of the entity
Actually, herein lies a religious war. One can use SGML *syntax* to
write things like <bold> or even <bold size=VeryLarge>. However,
conceptually, SGML is intended for use with "generic" markup and not
"formatting" markup or specification. With a conceptually reasonable
DTD and SGML, I would normally identify something as, e.g., a subsection
title and leave the definition of that to the definitions in a
particular processor, rather than identifying it as boldface, of a
particular size, and/or numbered in a particular way.
This is what makes SGML so popular with the folks who do research on
texts. While it can take a while to work out a DTD that captures
whatever is considered important, you end up a single source document
that can be formatted and displayed to the quality limits of the target
devices, even if those devices range from typewriters to photocomposers.
If my memory is correct, RTF provides formatting specification/markup,
not conceptual/generic markup.
But, to the best of my knowledge and understanding, Steve's overall
conclusion is almost certainly correct: Microsoft RTF, given adequate
parameters, would make a perfectly reasonable application subtype, but
it is not a good foundation for an Internet interchange format that we
are going to depend on for large-scale interoperability among
>I would actually be surprised if many other
>word processor vendors were supporting this format. (I'm not
>very familiar with the market, though, so my feeling could easily
The market is dominated by an instantiation of the mythical 300 pound
gorilla and the behavior patterns one predicts from that. Many, if not
most, MSDOS and Windows word processor vendors try to support this
format, often through separate conversion routines.