Re: indexes as links rather than documents
Dan Connolly <connolly@pixel.convex.com>
Message-id: <9211122041.AA23043@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: indexes as links rather than documents
In-reply-to: Your message of "Thu, 12 Nov 92 18:48:05 +0100."
<9211121748.AA00296@www3.cern.ch>
Date: Thu, 12 Nov 92 14:41:02 CST
From: Dan Connolly <connolly@pixel.convex.com>
>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>
Sure... I don't have any strong opinions about the syntax, except that
RELATIONSHIP is longer than 8 characters, and that will be an issue
with some SGML parsers.
This opens up the discussion of link semantics from a while ago. Some
folks suggested a TYPE or ACTION or RELATIONSHIP attribute on anchors:
SEE (the default) see HREF, i.e. this anchor refers to HREF
INCLUDE include HREF at this point in the document (for quoting)
REPLACE replace the anchor text with HREF (another quoting mechanism)
AUGMENT display HREF along with this document (for figures, etc.)
SEARCH search HREF and display the results
You could have zillions of options here: DEFINE (HREF defines this anchor),
UPDATE (HREF is a new version of this document), TRANSLATE (HREF is
some converted form of this document). But I suggest we call the attribute
ACTION, and only create a new one when there is a user-interface impact.
So the ACTION attribute is a hint from the author on how to display
the document. That way, all the DEFINE, UPDATE, TRANSLATE, etc fall under
SEE above.
>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.
But in practice, it's the same: if I quote a wais source from this
mail message, you'll have to 1) traverse the link to the index,
and 2) search the index.
> 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.
[Ever seen Dynatext? It supports query dialogs of this sort...]
Ah... this is a perspective that I hadn't thought of: that the
gopher search panel is analagous to the WWW index "cover page."
I was thinking of a model where in stead of a link from document X
to index Y and then another to search results document Z, the link goes
from X to Z, and searching the index is part of traversing the link.
It makes sense to me to have the links mirror protocol transactions.
In other words, if we have a two step protocol:
client: "I want to do a search."
server: "OK... here's the query form."
client: "Here's the filled-out query form."
server: "OK... here are the results."
Then the WWW model of "searchable documents" (query forms) makes sense.
But currently, we just have one step protocols:
client: "I want to do a search. Here's what I'm interested in..."
server: "OK... here are the results..."
So as long as the client can do all the preparation for the query
without help from the server, we should not penalize users with an
extra network round trip.
I don't think the network will ever be a non-issue.
>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.
Sure... we need to treat <ISINDEX> as shorthand for
<A NAME="k" HREF=_this_document_ ACTION=SEARCH></a>
As for making it global to the document, you could just treat the
first SEARCH anchor as the default index to search. In the linemode
browser, you could type "k words" to search the default index,
or "7 k words" to search the index assocated with anchor 7. In a GUI
browser, you could have a search text area, and a search button. The
search button would be inactive unless there are SEARCH anchors. Then
it would default to the first one, and clicking any other SEARCH anchor
would just "steer" the search button towards that index.
Dan