>> The idea I propose is to allow URLs to contain a search keyword for
>> client-side searching. Most browsers allow you to search a document
>> for strings.
>
>Sounds like a good idea. If done, we should support a syntax that
>has multiple keywords: http://x.edu/xxx#/jump,link,hypertext
We kicked this idea around a bit a couple of months ago. It's one that
we've discussed a bit with Spyglass, too, as part of the work that we're
doing with them.
There are a couple of related capabilities that might be taken into account
when designing the syntax. When dealing with large documents, retrieving
only a portion around the highlighted words. In Acrobat docs, Adobe is
providing the means to retrieve one page at a time, for example. Thus, you
could request the first page on which a highlight occurs.
In structured text, especially HTML, I suspect that nabbing a cohesive part
of the document while preserving the structure is a bit trickier, but
certainly worthwhile.
Finally, we'd also like to see browsers implement highlight-to-highlight
navigation.
HOWEVER... it has been pointed out by wiser minds that a proxy could
accomplish these things rather neatly. To wit, if the search server would
send the highlighting information and URL, then the proxy could go get the
document, highlight it and send it along to the client.
But wait, there's more. Instead of trying to pass all of this stuff in
URLs, which would become quite unwieldy, another suggestion was to create a
MIME type that would take care of these issues. It would contain the
highlights, etc., and either the document itself or a pointer (URL) to it.
The MIME document could be expanded into the highlighted document by the
server, a proxy or the client.
Finally, since there's a need to support multiple viewers, this should be
implemented in a way that will work with more than just Web browsers.
Nick