sears@sun.uucp (Daniel Sears) (07/27/88)
We have had an internal debate about SGML at Sun for quite a while. Other
groups may be interested in SGML for a variety of reasons, but we are chiefly
interested in document portability across different software and different
document structures. For example, a writer in Mountain View might use one
software package to produce reference material and a writer in Boston might
use another software package to generate on-line help. We want a markup
system that allows us to easily send documents between these different systems.
Right now, I don't have any specific reservations about SGML in the sense
of preferring something else. There isn't something equivalent to SGML
being developed by the Warsaw Pact that I think is better. But I do think
that SGML is being treated as a panacea when it doesn't deserve to be.
Here is an example of what I mean:
SGML provides rules for describing tag sets. So let's create two very simple
tag sets that we will assume are SGML conforming. The first has two tags and
the second has three.
TAG SET 1 TAG SET 2
==========================================================
<mark1> = paragraph <mark2> = paragraph
<mark2> = chapter heading <mark1> = chapter heading
<mark3> = section heading
Note that while <mark1> and <mark2> have opposite meanings in the tag sets,
it is possible to translate a document from the first tag set to the second.
But it is not possible to translate a document from the second tag set to
the first because there isn't an equivalent tag for <mark3>. What SGML
tries to guarantee is a way of describing the different tag sets, but it
does not guarantee that the tag sets will be rich enough to hold all the
objects that other tag sets may contain.
Suppose we choose to use the Association of American Publishers markup
system. This is an SGML-conforming tag set that was developed for the AAP.
It is quite rich with several hundred pages of supporting documentation.
Now suppose that we purchase a software package from a vendor who advertizes
an SGML-compatible tag set. Since we have two separate tag sets we must
have some mechanism for translating between them. This may not be a
straightforward translation and it may in fact be indeterminate, like
the example above. To compare this problem to the software engineering
world, it is like translating from C to Pascal. Both have brief BNR
descriptions, but that does not guarantee a straightforward translation
mechanism between them. Some C features like pointers don't have matching
counterparts in Pascal.
Right now, we are afraid to handle the task of translating from one package
to another. We talk of 70% solutions that leave a writer with a large task
of finishing up the detail work. I suggest that using different albeit
SGML-compatible tag sets will still leave us with a large programming burden.
This leads me to my conclusion about SGML: big deal. It solves a problem
for a tag set developer, but it doesn't solve my problem. The tag set
developer wants a set of guidelines for defining a tag set. I want a
mechanism for defining documents in a portable manner. These are very
different things. In summary, the goal of structured document systems is
quite laudable, but I think it is necessary to distinguish a system like
SGML from that goal.
--
Daniel Sears Sun Microsystems, Inc.
Technical Publications MS 5-42
(415) 336-7435 2550 Garcia Avenue
sears@sun.com Mountain View, CA 94043