Nick Arnett wrote:
> However this is done, it should have an eye toward eventually allowing a
> client to receive a URL and highlight information from the search server,
> so that, armed with those two smidgens of data, it can fetch the document
> and add the highlights all by itself.
.. and I'll concentrate on the "eventually" part here.
Wayne Allen wrote:
> In any case, I'd like to see a solution which does not require the
> search engine have access to the actual document at search time, and
> does not require the search engine or indexer to parse HTML.
I agree.
Because of this, and also because I'd like to keep a clear distinction
between {the base document} and {annotations to the base document (e.g.
highlighting for search results)}, I'd prefer a solution that doesn't
involve embedding <highlight>...</highlight> throughout the document.
Wayne's previous message described an approach that went some way toward
this -- putting the info in an attribute up in <HEAD> rather than
throughout the <BODY> -- but I'd like to go further and have the highlight
annotations completely separate from the base document.
The client-side highlighting issue did the rounds previously on www-talk
(January? Before the list died and was resurrected, anyway). At the time,
I was keen to add a MIME compound type that'd contain (a) either an URL
to the base document or an inline copy of it, and (b) annotations to be
applied to that document. Rob Hartill had cogent arguments for doing it
another way, adding the required information to URLs (as Dave Hollander
mentioned this time around). The info in the URLs might be a lot like
some of the (server-side) URL syntax that the WN server supports.
I'm still rather fond of the MIME type rather than info in URLs, but
either approach should satisfy my main criterion (getting the annotation
information out of the base document).
Also, either approach should be able to handle the requirement that Bill
O'Donnell pointed out: multiple representations of highlight information,
rather than just a word-list.
Thomas
[email protected]