In the current WWW model, an index is a document with an <ISINDEX>
tag. The browser displays the document, recognizes the <ISINDEX> tag,
and provides a search/find/keyword command. The user invokes the
search command and supplies the seed words. The browser conducts the
search transaction and displays the results. Then the user chooses
from the results.
In the model I prefer (which is used by gopher currently), and index
is an anchor with an INDEX attribute. The user selects the anchor, and
the browser prompts for seed words. The user supplies the seed words,
and the browser conducts the transaction as above.
In the WWW model, I run into lots of documents that just say "this is
a searchable index." Some index documents have instructions and
summaries of contents, but most are generated by gateways.
The WWW model actually fits inside the gopher model: where you would
use a document with an <ISINDEX> tag, use a document with an INDEX
anchor.
But the gopher model is more versatile. You can have one document
point to multiple indexes. You can have one set of instructions for
lots of indexes.
For example:
WAIS based information
Click here[1] for instructions.
directory of servers search[2] describe[3]
RFC's search[4] describe[5]
README's search[6] describe[7]
which might look like:
<!DOCTYPE HTML SYSTEM>
<TITLE>WAIS based information</TITLE>
<a HREF="wais_help.html">Click here</a> for instructions.
<p>
<dl>
<dt>directory of servers
<dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
<a HREF="wais://quake.think.com/directory-of-servers.src">describe</a>
...
It's easy enough to support the current model for backwards
compatibility, but I think the concept of an index as a type
of link makes more sense than indexes as a type of document.
Thoughts?
Dan