OO WWW: Re: indexes as links rather than documents
Tim Berners-Lee <timbl@www3.cern.ch>
Date: Fri, 13 Nov 92 17:04:45 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9211131604.AA01410@www3.cern.ch>
To: Dan Connolly <connolly@pixel.convex.com>
Subject: OO WWW: Re: indexes as links rather than documents
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch
> Date: Thu, 12 Nov 92 14:41:02 CST
> From: Dan Connolly <connolly@pixel.convex.com>
>
>
> >How about ...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.
Of course. We could call it REL. (That's what you get with IBM-derived
products ;-)
> 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.
There seem to be two classes of attribute we are talking about here.
Some attributes express a relationship between the documents (or
relationships between objects described by the documents). These are
relationships like
A is a previous version of B
A describes the author of B
etc. These add semantics to the web, allow interesting navigational
functions.
Other attributes are directions to the client app., to so something:
When you display A, also display B
When you display A, embed B
When you print A, also print B
When you follow this link, embed B
When you follow this link, search B
Let's bear in mind the idea of moving toward arbitrary objects.
The OO paradigm (the current one, not the only possible one)
has objects which each have a class, which has a set of
methods, each of which has a set of parameters, each of which
has a class. Ok?
Suppose documents are objects. We have two methods now,
render() returning HTML
search(text) returning HTML
each taking the object ID as an implicit parameter. That's OK.
These are neat functions. Suppose we generalize.
First generalization: the render():HTML is only one of many functions
which the object supports. The format negotiation says
"I want render()* where * is preferably ....".
In this context the <ISINDEX> tag means "The class of this object
supports search(text):HTML method". The SEARCHME link
looks more like some advance notice type information [[yuk -- I hate
having info in two places... links can get out of date -- but never mind]]
"The object references supports search()"
plus also the client advice
"When you follow this link, search B"
I would separate these two things, personally myself. the first is useful
for deciding on the icon to display, without the second which coud
independently be any of the other client hints mentioned above.
In this light, it would seem there are some obvious extentions!
Let's skip the debate about whether you want the client advice attribute
to make an automatic search (OK, let's put it in, no harm in it)
and focus on the type declaration. Whether it is declariung stuff
about the document itself or a related document is a trivial difference,
the difference between the LINK and the A tags, in fact.
So lets generalize ISINDEX. We have a choice. We can declare the class
(or any superclass) of an object. Or we can declare a method. In fact,
in the multiple inheritance view, these are very similar as you can
imagine a class which only supports one method, and then construct
classes out of inheritance only from those classes. So declaring a
class (set of methods) is more general than declaring a method.
An immediate application of this will be declaring things like
Z39.50 objects which support various search methods with all kinds
of different input parameters. But one wouldn't of couse stop there....
Classes, like representations, would have to be registered. Either registered
or defined in a suitable language by a document. Ha! we know how to handle
that.. we don't even have to worry about the class description language
because we can apply format negotiation to that. In fact, registreation
of a class with IANA would involve storing the class description in a document
was in a well-defined place, and of which everyone would take copies.
I mean like maybe even at compile time for classic classes.
(I would expect that a convention for getting an icon graphic from
the same directory as the class description would be kinda nice.)
So a document start with information about itself
<!doctype HTML USDN=x.500:/ch/cern/cn/92/tbl
URL=http://info.cern.ch/tbl/mydoc.html>
URL=ftp://info.cern.ch/pub/www/doc/mydoc.html>
<type USDN=x.500:/internet/iana/www/textindex
URL=http://www.iana.net/class/www/textindex.asn1
ACTION=textsearch>
Hi this is an index of all the widgets in the wdgetbox.
We need one (1) language to start with for defining the classes.
ASN/1 or a SGML version of ASN/1? So long as it can include
inheritance from other classes using a hypertext reference.
We still require all documents to be renderable, which just means
that all objects support render() returning either HTML or
ascii.
> >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.
Like with the chicken and the egg, it depends when you start counting the
clicks.
>
> 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."
Isn't that slower? In fact what happens is the user thinks like
that, but the client, knowing that a search is possible, happens
to put up the search panel. Could we in fact use a
"when you display A, display B too" link, here?
>...
> I don't think the network will ever be a non-issue.
>
I agree. Speed of light, for one thing.
> 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.
I would prefer to use a document-wide LINK element
in the header as a document-wide analogue of the A element
but that's a detail.
Tim