> I keep running across interesting bits of evidence that tell me that
> indexes should be a type of link rather than a type of document.
>
> <dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
> <a HREF="wais://quake.think.com/directory-of-servers.src">describe</a>
>
Dan,
If you found that most index documents are empty, then that was probably
because you were in gopherspace -- in waisspace they all have descriptions.
[[even though as Ed points out the description lives in one place and the index
in another so it is dificult to know which address to use! On that point,
ed, I chose to refer to the index as that is what actually MUST be available,
when the source file is not essential, it is just icing on the cake]].
How about above instead of
> <dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
using
> <dd><a HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>search</a>
This expresses that the type of relationship between the documents is
that when you follow the link you should search the seocnd index.
An important addition is just a document-wide
<LINK HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>
empty element which makes a document searchable, directing seraches
to a given index. Similarly RELATIONSHIP=GLOSSARY would
allow double-clicked words to be looked up in a remote glossary.
This would solve the problem with WAIS source files, in that their hypertext
representation would have such a link to the index, so the source file itself
appears searchable. There are lots of places where this would be neat.
We have been over this a little before. Perhaps we should allow either
option, as it is so checken-and-egg as a problem.
The argument for the W3 model is that often the user will want to search
or not search a single index, and he doesn't want two operations: one to
select the fact that he wants to search (click) and one to search
(typetypetyepe return). He just wants one. After all,
if he clicks on a gopher index link, what does he get? a serach panel.
And what is the difference between that and a serachable document?
Only speed of display. If the serachable document can come up as fast as
a search panel, then there is no contest. If not, there is.
In the long term the search will become (if my philosophising of
the oher day comes true) an instance of a class of search query, for which
an editor will exist if the client supports it. So searches with
toggle buttons and radio buttons and stuff will be possible,
and a gopher serach and W3 search will be subclasses.
I feel that we are talking about optimising speed when the net is slow
here. In general, I don't want to talk about a dictionary (search[1].
describe[2]) I want to talk about a dictionary[3]. The former seems kinda
messy. It just saves time given a slow network now...
Tim