Passing highlight information in URLs

Nick Arnett ([email protected])
Fri, 25 Nov 94 11:06:26 PST


I'd like to raise an issue that's beginning to become important in our Web
strategy. As you may know, when search engines return documents, they
typically include "highlights," which are some kind of markup and/or
navigational aid that shows why the document matched the query. For
example, if you search on "web and publishing," the document might be
returned with the words "web" and "publishing" in boldface. From a
navigational standpoint, you'd usually want to open the document to the
first occurrence of the highlights, then be able to use a single keystroke
to jump from one to the next.

I think we need a generalized approach to passing highlights among viewers,
via URLs. The idea is that whenever a server or a viewer tells a viewer to
open, it's also able to pass the highlight information. Otherwise, the
server or viewer would have to proxy every document in order to add
highlights.

Inevitably, there are going to be multiple viewers launching one another,
I've come to accept. There's Mosaic and its kin, Acrobat, Panorama,
various other SGML viewers, plus proprietary ones such as our client-server
products. Clearly all want to be able to launch one another as helpers, if
not as peers. For example, we want to be able to search Web indexes in our
own viewer, then launch an HTML browser to view the document.

I think that the inefficiency of proxying is obvious, but I'll say it
anyway, with an extremely inefficient example. Let's say you're in
California and you search a server in the UK. One of the resulting
documents is on your own network. If the server has to do the
highlighting, it'll have to retrieve the document from California, do the
markup, then pass it back to California. If it can simply pass the URL
with highlight information, then your viewer can retrieve the document
locally and do the highlighting.

Obviously (I think), there should be a standard way to pass this kind of
information, useful to a variety of kinds of viewers and browsers.

I'd be especially interested in comments from those who are doing viewers
and browsers for the various non-HTML document types, since that's where
I'd assume that our shared knowledge is thinnest.

Nick

--------------------------------------------------------------------------
Verity Inc.
[email protected]
<URL:http://www.verity.com/>