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:FWD Re[3]: SGML and features database From:Joyce Flaherty <flahertj -at- SMTPGW -dot- LIEBERT -dot- COM> Date:Sun, 31 Mar 1996 15:17:38 EST
Text item: Text_1
MH: Mark Halpern mark_halpern -at- tesseract -dot- com
MH: Joyce, ...You may forward my message, or post it to the
MH: list, as you wish. Mark Halpern
===============================
JF: I wish, so here it is:
from my original post:
... we identified all relationships for every software item (system,
program, module, macro, clist, proc) we owned. The relationships we
identified and fed into the dictionary provided the query function:
"what uses X?" and "what is used by X." We used the dictionary to
measure the impact of a change, among other things.
It seems to me that an unambiguous, richly-encoded, highly
content-tagged SGML database that apes the data dictionary would
provide the *features* function we want. If a customer wants product
X with options Y and Z, you retrieve the doc to support product X AND
options Y and Z. Then you add to doc entity Y and Z the *used by*
attribute. I'm still struggling with how much of this information in
stored in the SGML database, and how much is more appropriately
maintained externally.
========================================================
Joyce,
You have described a capability that I have thought about for a
somewhat different purpose, that of building highly reliable complex
progams from well-tested, catalogued software building blocks.
In thinking about what it would take to be able to build such
highly reliable programs from components of which you were not the
author, it seemed to me that you would want to know, for each such
component, what sub-components it used, and what larger composites
used *it*.
As you say, such a usage-tracking capability is important to make
sure that you have all the pieces some application needs, and likewise
to ensure that you have removed all the subordinate pieces (except
those used by some other application) when you uninstall an
application. It is also a capability you need when, for example, you
are loading your laptop with (you hope) all the stuff you need in
order to work at home, or to put on a demo, but nothing that you don't
need, since disk space is at a premium.
If you find any utilities that offer this kind of capability,
please let the rest of us know (or at least those who express an
interest); I'll do the same for you. Thanks,
Mark Halpern
mark_halpern -at- tesseract -dot- com
