Documentation Database

["Dimock, Dick" <red -at- ELSEGUNDOCA -dot- ATTGIS -dot- COM>]

There has been some discussion of using databases to
assist the documentation process.

Here at NCR (old AT&T GIS), our division sells huge database
platforms and software.  It is only fitting that we TWers in this
database environment be on the forefront of using database
technology to produce our world class, leading-edge, even
best-on-the-block documents.

I have developed what I believe is the Next Generation of
Desktop Publishing tools, using our vast database of
(naturally) database manuals.

We have such a large stock of published database docs
that statistical analysis becomes quite accurate.  It is on
this basis that I was able to proceed with development.

There has been much debate about the importance of
page design, attractive layout, fonts, etc. as opposed to
actual content.  Actually, both parts of the TW art are easily
and simply achieved via my "Database Documenter".

Large corporation standardization demands a tight control
on format and appearance, and we have standard templates
covering the entire documentation family. Thus automating
the actual appearance of the generated documentation was
a simple matter.

Amazingly, the actual content of the doc also can be quickly
and expertly generated, providing the existing database
of documentation is large.

The approach I used is actually a simple one.  The concept
came to me in a dozing-dreaming state during a corporate-
wide satellite video speech by good-old-whats-his-name.

**Statistically speaking, there is a specific chance that one
word will appear as the first word of a manual.

**Statistically speaking, there is a different, yet still specific
chance that another word will appear as the second word of
a manual.

Assigning each word position the most frequently-used
word for that position results in the exact word sequence
that is most representative of our database product.

(I had suspected our marketing department had something
like this going, but they had not actually automated the
process as I have for Documentation.)

Given our large population of manuals covering a wide
variety of database products, the reliability and repeatability
of generating new docs from the database is extremely
high, and productivity has been increasing on an exponential
trend.

The size, page count, appearance all are becoming more
corporationally uniform. There are few spelling errors.  Editing
is rarely needed, because the original docs in the database
were never edited in the first place.

The impact has already been noticeable to the outside world.
The efficiencies and productivities resulting from my system
have allowed AT&T to "readjust" her labor force world wide,
and to bring our Chairman, Bill Whats His Name to reorganize
the AT&T empire.  (Once I revealed to Bill my "Database
Documenter", ol' Bill got a faraway look in his eye and dashed
back to Galactic Headquarters to implement the concept
within the accounting arena.

Now it is a bit lonely around here, but at least I can handle the
new product docs with ease, single handed.  There are even
fewer developers needed nowadays, since product code is
now produced via the statistical methods I pioneered.

Unfortunately, I have no data about how well this method
would work with original database manual populations below
10,000. The technology may not downscale easily, and if ANY of
those manuals in the database have been EDITED, the
outcome is unpredictable.

That's the definitive word from Them That's Doin' in the
"Documentation Database" world.  FWIW.

Regards to all!

Dick Dimock    Artfully Senior TW with

NCR Corp. Which is easier to type than AT&T GIS, in
          Beautifully Sunny

El Segundo, CA Where 10 inches of rain has scrubbed
          the city clean.  Even the Chevron
          refinery sparkles...  for the moment.
          The lake in the middle of the Hughes
          athletic field has mostly drained away.
          Mud slows the joggers.

richard -dot- dimock -at- elsegundoca -dot- attgis -dot- com