Article View: comp.text.sgml
Article #432Re: What is SGML?
From: Erik Naggum
Date: Tue, 19 Feb 1991 12:28
Date: Tue, 19 Feb 1991 12:28
233 lines
13865 bytes
13865 bytes
Hi, all, and sorry for the delay.
The following is an unfinished introductory article that I don't have
the time to finish quite as soon as I had hoped. Please comment on
it by sending me a message at <erik@naggum.uu.no>. Thanks.
Evan, I hope this will give you a flavor, if not the Whole Answer.
[Erik]
What is SGML?
SGML is the abbreviation for Standard Generalized Markup Language. If
you know what Generalized Markup is and what Markup Languages are and
do, the only remaining element is Standard. SGML is International
Standard 8879 as issued by ISO - the International Organization for
Standardization - in 1986 and later amended. Many people apparently
knows what Generalized Markup and Markup Language means, since SGML
quickly became popular and is rumored to be one of ISO's best selling
(or fastest selling, according to other rumors) standards. However,
it seems even more people do not know what generalized markup is or
what markup languages are or do, but nonetheless, they've heard that
SGML is going to have an impact on how they do their work. Those who
work with SGML certainly hope so.
In this article I will try to explain some of the key concepts that
led to the birth of SGML and how they manifest themselves in the
language. In addition, some key concepts of the language are
presented for the casual observer. Later articles will deal with
these issues in more detail.
Markup
The specification of typefaces, sizes, weights, spacing, indentation,
justification, etc, for a given text before it is printed (or typeset)
is called marking up the text. Traditionally, this has been done by
writing small cryptic signs in the margin of the copy (text), much
like proofreaders marks, for those who have seen them. For instance,
the abbreviation "SGML" could be set in small capitals, keywords could
be set in italics, paragraph titles in boldface, a point or two
smaller than running text. Examples could be set in some monospaced
font such as courier, quotes in the same typeface as running text but
two points smaller on a narrower line spacing with a shorter line
length and a little indented from the left margin. All of these
rather detailed specifications were instructions to the typesetter.
Incidentally, we now call such markup "specific markup".
Authors have generally not had to know anything too specific about
typography. Most of them used typewriters or had someone type their
manuscript from dictated tapes, if they didn't write it out in
handwriting. However, they had to communicate the structure of the
text to the person doing the markup, even though that person added
many choices of his own. A minimum would be to separate paragraphs
from each other, the headings from the text, examples from running
text, etc. Some of the more obnoxious authors no doubt had specific
ideas on how it should look, as well.
As one comes to learn of the art of printing, one becomes awestruck
(or should, anyhow) by the magnitude of the possibilities and choices.
Typographers in the field of advertising exploit this to the fullest,
but if you produced a book with the same typography as in ads, it
would look horrible, and be unreadable. Typographers deal with the
aesthetics of the printed page, while the copywriters concentrate on
the message. Similarly, authors concentrate on the content of books
and articles, deferring typographical decisions to people who master
that part of the process. This is not always the case, as we shall
see, and some software for popular hardware platforms deliberately
confuse the issues of contents and style.
Information and presentation
Ironically, in a world of ever more specializing, it's important to
distinguish between two aspects of any communicated piece of
information that few would ahve thought could be confused. When you
pick up a newspaper or a book, you don't do so to admire the clean
typography, the beauty of the typeface, or the orderly layout (unless,
of course, you've spent some time under the wing of an old-school
typographer, and write articles about what SGML is); you pick it up
because the information looks interesting and worth reading. Many
would argue that people are unlikely to do so if a whole 100-page
newspaper consisted of page upon page of 8 columns of text packed
together with no change in type, no superfluous spacing, no paragraph
breaks, etc. (The Frankfurter Allgemeine to the contrary notwith-
standing.)
On the printed page, information and presentation work together to
bring the author's ideas and observations to the reader, as they do
with the lecture, where a live lecturer with a rich voice and varied
diction can do wonders to otherwise heavy material. In the result,
information and presentation invariably coexist, and it would indeed
be difficult to imagine either without the other. This does not imply
that the two are not radically different processes, and that the basic
tenet is that information must have some form of presentation, but it
can be any form of presentation, and that a form of presentation must
by applied to some information, but it can be any information. Thus
we deal with easily abstractable concepts. Let's take them each in
their turn.
Information usually has some structure. Books, e.g., may have parts,
chapters, sections, and paragraphs. They may have front matter, such
as a foreword, a preface, table of contents, etc, and back matter such
as bibliography, author biography, index, etc. Further, paragraphs
can't contain chapters or a table of contents, but may contain other
tables, figures, quotes, footnotes, etc. This forms a hierarchy of
elements. (There are also non-hierarchical elements, such as index
entries, references to chapters, paragraphs, tables, figures, and so
on.) This structure is almost always in the head of the author, and
not put down on paper in detail. This unfortunately lends itself to
inconsistencies, and in particular where special conventions are used
to indicate different parts of the structure.
A style, or consistent form of presentation, has a close relationship
to the structure of the information to which it applies. Titles of
chapters look the same, as do figure and table captions. Footnotes
obey a certain regularity, etc. It should be evident that a style
associates each element in the structure with a particular set of
typographic instructions or specific markup as mentioned above.
Because of the relationship between structure and style, we talk of
text which only carry indications of the structure as being marked up
with "generalized markup". The implication is that we can choose any
style for the structure in question, and that the author won't have to
make any changes to the document if he (or the typographer) changes
his mind about, say, footnote presentations, or the particular size of
the typeface chosen for chapter titles. It should even be possible to
produce the table of contents directly from the document by listing
the titles of the chapters, sections, paragraphs, etc, and ignoring
all other content. Similarly, of course, with list of figures and
tables.
It should be quite obvious that if all a document contains is specific
markup, it would be impossible, without vast amounts of human inter-
vention and artificial intelligence, to figure out what is a chapter
title and what is a figure caption, mechanically. To the reader, this
is of course very simple, but we must remember that this is courtesy
of a long tradition among typographers who have managed to present it
all to us in a clean and consistent fashion. Humans also recognize
what's a title and what's content by the form of the text therein,
which a computer program would be hard pressed to do. Physical
arrangement on the page also helps, especially when more novel or
experimental layout is used to represent keywords in the margin,
titles in boxes on one side of the page, and so on.
The separation of information and presentation is thus most helpful
for machine processing of documents. The argument is that most new
documents are written with the aid of computers and that even for
small amounts of machine processing, consistency is a virtue. It is
cruel to demand of the user that he maintain the consistency with no
aid from the otherwise useful computer. That is why languages are
designed to help the author inform the computer of his intentions, so
that the computer both can check consistency and be of the most help.
After all, such chores are what computers are well suited to perform.
Markup Languages
Before discussing generalized markup languages, a quick presentation
of markup languages in general is called for. Instances of markup
languages abound, and many have seen WordStar's dot-commands, TeX's
backslash-introduced magic, and the intertwined text and control lines
of nroff and troff. Less intuitively, the special codes used by the
soi disant WYSIWYG ("What You See Is What You Get") editors are very
simple markup languages, because only the editor is supposed to see
them. Users are "relieved" from knowing what's going on, and are thus
not able to use the document in anything but the environment in which
it was created. Personally, I regard such closed environments as an
abomination, and want nothing of it. Text and documents are much too
important to be left to "integrated packages".
nroff and troff, to take but one example, or two of a kind, really,
since they take the same input language and prepare output for two
different classes of devices, take as input a document consisting of
interspersed text lines and control lines, where the control lines are
distinguished from the text lines by having the first character on the
line be either a period or an apostrophe (or acute accent). Other
lines are text lines and are processed according to the instructions
provided by the control lines. The primitive operations in nroff and
troff are based on typesetter primitives, in addition to some powerful
operations on registers, text justification and line drawing. The
input language also supports expressions and conditionals. Another
important feature of the input language is the ability to define
macros for oft-repeated sequences of primitives. More than that, the
macros may take arguments and pave the way for a generalized markup.
Indeed, several such exist for many applications. E.g., the UNIX
manual pages are all described with a highly generalized markup.
Unfortunately, the language is somewhat restricted and is considered
difficult to learn by the people who decide such things. There exists
preprocessors for both equations, tables and pictures, and the result
can be found in a large number of books. Most notably, the results
are in line with sound typographical conventions, and even though it's
possible to recognize that a book was set with the aid of troff,
typographers are pleased with the result.
TeX, on the other hand, contains a gargantuan amount of primitives (or
not so primitives) and is a vast and complex language which is hard to
learn and master, but which is said to be particularly well suited to
typeset mathematics. It is extremely cumbersome to use in its raw
version. TeX also supports macro definitions, and indeed this is what
most TeX coding is about. However, the confusion of name spaces in
TeX (something which is not present in nroff or troff), makes reading
the macro libraries hard and changing them error-prone. Large macro
packages and preprocessors exist, e.g., LaTeX, which function as
generalized markup, except that is it difficult to use the input for
anything but the particular preprocessing software. From the stand-
point of a seasoned typographer, the output is gross and can easily be
recognized even by the untrained eye.
Both of these, and undoubtedly most other, markup languages are
concerned with producing output on some (range of) devices. In this
manner, they are really specific markup languages with generalization
support, instead of being generalized markup languages with specific
markup support.
The Standard Generalized Markup Language is the first major attempt at
a truly generalized markup language; the main feature of which is the
ability to specify the structure and check it for consistency. Any
document which use a particular structure can be validated with
respect thereto. SGML does not concern itself with producing output
on any device; that is handled by an SGML application, external to
both the language and the document. What then, does SGML do?
An SGML document consists of several parts, which need not be found in
the same file. (Powerful means exist to enable any organization of
the document.) From SGML's point of view, the DTD (Document Type
Definition) is the most important. It defines a type of document in
terms of its structure. From the authors's point of view, the
document instance is the most important. This is the authors's
content within the structural definition defined by the DTD.
<< More to come >>
Technical Details
Message-ID:
<ENAG.91Feb19132846@holmenkollen.ifi.uio.no>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!nuug!ifi!enagReferences:
<494sis-b@massey.ac.nz> <ENAG.91Feb8030457@holmenkollen.ifi.uio.no>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!nuug!ifi!enag From: enag@ifi.uio.no (Erik Naggum) Newsgroups: comp.text.sgml Subject: Re: What is SGML? Message-ID: <ENAG.91Feb19132846@holmenkollen.ifi.uio.no> Date: 19 Feb 91 12:28:57 GMT References: <494sis-b@massey.ac.nz> <ENAG.91Feb8030457@holmenkollen.ifi.uio.no> Sender: enag@ifi.uio.no (Erik Naggum) Organization: Naggum Software, Oslo, Norway Lines: 233 In-Reply-To: enag@ifi.uio.no's message of Fri, 8 Feb 91 02:05:05 GMT