TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Why SGML? From:Len Olszewski <saslpo -at- UNX -dot- SAS -dot- COM> Date:Mon, 18 Dec 1995 21:04:46 GMT
In article <30d068f7 -dot- tedopre -at- tedopres -dot- nl>, Simon North <snorth -at- tedopres -dot- nl>
writes:
|> There are three basic reasons why SGML:
|>
|> 1. longevity
|> 2. re-purposing
|> 3. re-use
[...good explanation of these reasons elided...]
Another good reason is electronic interchange of information in standard
ASCII formats. With a well-defined DTD and a convention for using it,
you can exchange standard information sets with the assurance that each
item you exchange will conform to the standard, and everyone in
compliance will get what they expect (as far as processing requirements
are concerned). This is important if you are distributing text for
translation to other languages, for example. Or distributing hardware
specs among a consortium of commercial or governmental enterprises, for
another example.
A good SGML implementation never *prevents* you from going to any
format, and tools that provide standard database handling for text
marked-up with SGML are just about there. So you can manage your text in
a predictable way, version it down to a granularity you never thought
you could, maintain configurations independently of the text modules
that comprise them, and automate the means by which your links are
invested and maintained (in a platform independent manner).
It's not for everybody. But it has advantages over format-driven
approaches that become clearer when you have a *lot* of standard
documentation to produce over a *lot* of different formats in a *lot* of
different versions and configurations, AND limited staff resources to do
it. If you just produce relatively small amounts of documentation in a
single medium, do Framemaker, or something like that. SGML lets you
achieve efficiencies in division of labor for document production in the
large; it can be inconvenient and a little bulky for smaller-scale
operations.
--
Len Olszewski My opinions; you go get your own.
saslpo -at- unx -dot- sas -dot- com