Re: Document Databases & Intranets

Subject: Re: Document Databases & Intranets
From: Chet Ensign <censign -at- INTERSERV -dot- COM>
Date: Sat, 25 Jan 1997 13:33:17 -0800

Ruth Glaser asked:

>> ... 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. <<


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

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:

<TITLE>Performance statistics for 600K Core</TITLE>
<PFAM>coreware communication</PFAM>
<DTYPE>application note</DTYPE>

(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:

<h3>Document Types</h3>
<it><a href="techdoc/sgml/html?field=dtype fieldop=contains
fieldvalue="application+note">Application Notes</a>

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 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
Search the archives at or search and
browse the archives at

Previous by Author: Re: Version Release Notes
Next by Author: Re: Document Databases & Intranets (#601741)
Previous by Thread: Document Databases & Intranets
Next by Thread: Re: Document Databases & Intranets

What this post helpful? Share it with friends and colleagues:

Sponsored Ads

Sponsored Ads