Re: indexes as links rather than documents
Jim Davis (davis@dri.cornell.edu)
Thu, 12 Nov 1992 15:40:14 -0500
Date: Thu, 12 Nov 1992 15:40:14 -0500
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199211122040.AA13231@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: indexes as links rather than documents
As I understand it, the distinction between an indexed document
and an ordinary one is that an indexed document is really
an abstract document. Once you provide the index terms,
then it is concrete document. So a Dictionary is abstract
until I send it a keyword, then I get back a real document,
the definition for the word.
In the case of the dictionary, of course, one could argue
that the Dictionary as a whole is also a concrete document,
since it would be possible to just read it cover to cover.
On the other hand, this makes less sense if the abstract
document is performing some kind of computation on the
search words, for example, running finger, or even adding
something to a database. Then there is no meaningful document
without the index.
If that's the right way to think, then it makes sense to put
the semantics into the link, because it's more extensible.
In the case of the index, the user is prompted for keywords,
because that's the input to the computation. But
there are many kinds of abstract documents, and many possible
computations to yield concrete documents, and for many of
these there will be other kinds of input requirements.
It seems inelegant to support these by having the abstact
document indicate its input requirements by returning a
document with a special purpose tag (eg <ISINDEX>), since
this will mean that every new kind of input will require a new
tag in HTML.
Maybe this can be addressed in HTML2, by some process of negotiation
between server (abstract document) and user/client. e.g the document
sends something back saying "I will give you a page of text but
first send me at least one line of ascii". If this is the
right approach, then we need a means of describing data types and prompts.
The negotiation might take several exchanges, or it might be done
by having the server return a small program, something like a decision
tree, to prompt the user for all meaningful values required for
the input.
While I am on the topic, though, the protocol should be designed
such that software agents on the client side can obtain documents
without having to negotiate, if they have all the desired inputs
ready to hand. I don't want my user agent to have to parse X
windows protocols in order to answer on by behalf.
Best wishes