Excerpts from direct: 11-Sep-91 Re: Character-set header (w.. Ned
Freed(_at_)hmcvax(_dot_)claremo (9048)
The point of markup languages is that you can deal with them
effectively without regarding them as images, or application material, or
whatever. They are text. Repeat after me: TEXT. I don't know or care about the
layout details until I enter final production on the document. (I usually
never
do this -- it is up to someone else to do final production work.) In the case
of SGML is definitely is not my concern -- I cannot even control how things
are
going to be laid out in the SGML I use; formatting is totally external.
I understand and appreciate the argument you are making here. I often
use it myself. I regret the fact that people are obsessed with things
like page layout and font selection. I regret that the world has chosen
to use things other than text for exchanging information. It cuts down
terribly on our ability to automatically process information.
But we don't want to ignore reality (not just at the moment, anyway :-).
It is possible to define SGML DTD's for packets of slides, say, in
which all you have is a set of pages, each an encapsulated PostScript
image. (It is somewhat silly to talk about "SGML format" without
talking about a particular DTD.) This is then a valid SGML document --
and you can't read or edit it with a text editor. (In fact, this is a
kind of document we have been generating with alarming frequency since
we started using LiveBoards, which support pen-based bitmap notes).
This is also true for troff and TeX. So it is impossible to assume that
an *arbitrary* SGML, troff, or TeX document can be dealt with in a text
editor -- though *most* such can be. I also feel that this kind of DTD
will be in ever-increasing use as people scrap out character-oriented
hardware and replace it with audio-and-pixmap-capable terminals.
Now, you claim that you can encode arbitrary data in these formats. Well, it
is
not easy to do in any of variants I use, that's for sure. All of these formats
provide image inclusion facilities, but inline encoding of images is not a
useful thing to do.
All depends on your tools. All I'm saying is that the format allows it,
and we're going to see more and more of it as time passes.
It is certainly possible to write PostScript where only the header is a
complex
mess of commands and the rest of the document is plain ordinary text, and in
fact many documents are actually prepared in this way.
And this would form a subformat of PostScript that would be valid under
TEXT-PLUS, certainly:
Content-type: TEXT-PLUS/POSTSCRIPT-MARKED-UP-TEXT
But that's not the same as arbitrary PostScript.
If TeX, LaTeX, and SGML are moved somewhere else
while NROFF remains, I vote we get rid of text-plus completely since it is
clearly not useful, and its definition is obviously capricious and arbitrary.
NROFF isn't really a format, is it? It is a subformat of TROFF,
restricted to text+layout only. Similar subsets could be defined for
TeX, SGML, etc, and might be of significant value. But if that kind of
semantics isn't associated with TEXT-PLUS, then I suggest that it
becomes synonymous with APPLICATION.
Bill