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.
>> ... information on document databases as they
relate to intranets (as in storing documents in a database, allowing users
to specify what they are looking for, and returning dynamic HTML documents
suitable for viewing or printing through a browser.)
.. but no one had much experience
with them - although a few people were exploring the idea. <<
Ruth,
Last summer I didn't have much experience, but I've gotten a lot since. Just to
give you the benefit of my learning curve, here is one concrete example of such
an application.
I developed a document database for a client in the semiconductor industry. The
underlying tool I used was BASISplus, and BASISwebserver from Information
Dimensions in Dublin, OH. (Web site is at www.idi.oclc.org.)
This client wanted to make information about their products available to
engineers and product designers from a password controlled portion of their
public Website. They wanted to be able to list them by product family (ASIC
products, Communications products, etc.) and document type (white paper,
technical manual, application note, etc.) as well as by title. They wanted
users to be able to search the database by title, by text within the document,
by text within headings or subheadings, and they wanted to be able to filter by
product family, subfamily, and/or document type. Lastly, they wanted to be able
to maintain the collection automatically, because this will eventually
encompass thousands of documents. (You can imagine what it would take to
maintain several toc's with thousands of entries by hand!)
We handled this by converting the documents into a modified HTML markup. In the
head element, we defined several non-HTML elements that the BASIS engine would
use. There was dtype, pfam, psubfam, and a couple of others. So the head
element of an application note might look something like this:
(I just made that up -- I don't have any examples right at hand.)
When the document was checked into the database, BASIS would recognize the pfam
and dtype elements and put their values into appropriate fields for the
document's metadata. These were fields in a record that could be searched by
the application. The document itself was checked into its own container.
In the Web pages that gave access to this document repository, we then set up
anchors that were search phrases rather than urls. Again, I don't remember the
exact details, but an anchor for application notes might look something like:
When a reader sitting at his or her workstation clicked on "Application Notes,"
the href string was sent back to the server which passed it to the BASIS
Webserver. It queried the database, build a toc of links to all records that
matched the search string (all that stuff after '?') and sent them back as
formatted list.
This was very maintainable, of course, because when a document was checked into
the database, it instantly appeared where it belonged in all the various lists.
And, if the client needed to reorganize the lists, we did not have to rebuild
100s of links. Much of what we needed to do could be handled by changing the
search strings in the links. I did that several times.
Also, note that when I left the company, we were putting in whole tech manuals.
They were in there complete with drill down tocs and ability to filter, etc. as
well as working on a system that let clients fill out a profile, then be
notified when new documents were added to the database.
This project was not without problems, and it didn't turn out to be as good as
it could have, or should have, been. But none of the problems would I would
assign either to the product or to the client.
BASIS has a learning curve associated with it that is steeper than most
products, but what you can do with it is truly impressive. And I firmly believe
that the document database -- especially where it is coupled tightly with the
editorial environment -- is the future of our profession.
I hope you find this useful. Feel free to contact me if you have questions.
Best regards,
/chet
---
<signature>
Chet Ensign Office: 212-448-2466
Manager of Data Architecture Home: 201-378-3472
Matthew Bender & Company, Inc. Email: censign -at- bender -dot- com
New York, NY
</>
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
