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: SGML and features database From:Chet Ensign <Chet_Ensign%LDS -at- NOTES -dot- WORLDCOM -dot- COM> Date:Wed, 27 Mar 1996 10:10:14 -0600
There's some excellent discussion cooking of late. Apologies for my absence,
but I'm only in a couple of days a week right now. I'll be cruising through the
"new paradigm" discussions at luch. It's turning into a good discussion.
Joyce Flaherty asks:
>> What are we talking about in the SGML environment when
>> we say that we must "preserve the recipe for version control?"
I did not see the discussion that the quotation came out of (and if I said it,
then I'm going to be **really** embarressed by that admission), but I'd say
that the primary point about SGML encoded information is that you can define
version control requirements to meet your needs and then figure out how to
apply them to any level of the document. Version control is no longer just one
thing because you can get direct access to components of the documents.
The way I look at it is that, for binary-type documents -- WYSIWYG files -- you
get blob version control. Packages are smart enough to delta the differences
between the current file and the old file, but the delta is just bits, it is
not identifiable information.
Tagged file documents like Script on IBM mainframes or LaTex on UNIX let you
establish conditional text and external text that can be included by reference.
A version control system can now be set up to manage different versions of
those identifiable blocks of information.
You could do the same thing with SGML, as a tagged source file. SGML also gives
you the option to add more levels of control into the system. First, you can
define metadata elements to travel along with documents or their components.
For example, you might define a <version> element as part of the preliminary
info for a document and have the system update it each time the document is
published. Or you might define the version attribute for every section of the
document <sect version="1.001"> and update that every time the section's
content changes. You can find a way to put tracking information on any discreet
component of the document you choose.
The object-oriented document databases that are hitting the market now are
employing a variety of techniques to keep every element versioned, if you
choose. And, key issue, you can keep them versioned through editorial cycles,
then collapse all the versions down once the document is offically "published."
I think that the key thing SGML brings to the revision control table is that
ability to provide access and control at whatever levels of detail that you
feel are needed. Does this help?
Best,
/chet
Chet Ensign
Logical Design Solutions
571 Central Avenue http://www.lds.com
Murray Hill, NJ 07974 censign -at- lds -dot- com [email]
908-771-9221 [Phone] 908-771-0430 [FAX]
