Re: Client-side highlighting; tag proposal

> Date: Fri, 10 Mar 1995 10:48:54 +0500
> From: Gavin Nicol <gtn@ebt.com>
> 
> >We'd like to suggest a very simple approach -- a highlight tag.  This way,
> >our server could add the highlight tag in the appropriate places, but it
> >would be up to the browser (under the user's control, presumably) to decide
> >how to identify highlights in the text (turn them red, underline,
> >whatever).  An appropriate UI enhancement would be the addition of a "next
> >highlight" button or menu item and optionally a "previous highlight"
> >button.
> 
> I guess I am a strong proponent of "clean" SGML, but I must admit,
> that having some way to mark highlights would be very
> desireable. DynaWeb has fairly sophisticated searching capabilities
> (cross collection, boolean, proximity, structure-based, etc.) and
> I used the <B> tag for highlighting the hits.
> 
> This has 2 major problems:
> 
> 1) If DynaWeb highlights something already in <B>, you can't see it.
> 2) Even in plain text, it can be hard to see.
> 
> One problem with the tag approach is that we face a problem when a hit
> crosses element boundaries. This is not too much of a problem in
> DynaWeb *now* because most of it's tagging in the SGML to HTML
> conversion process is based on containers, but as HTML becomes more
> complicated, and more structured, it will become easier and easier to
> generate bad SGML.
> 
> Again, like the anchor that crosses element boundaries (that Dan
> mentioned) we have a problems, and I do not think start/end tag pairs
> solve the problem in an elegant manner. Some parts of the HyTime
> spec might be better, or concepts from it anyway.
> 

Another minor problem that I see with the tag approach to highlighting
is the possibility of the same URL being associated with 2 or more different
htmls contents.  

That is, your search engine asks for content with word X returns the url of
html page A which contains page A with all the X's surrounded by the highlight
tag.  Then, another search request for content with word Y happens to return
page A (coincidentally contains Y too), but here with all the Y's tagged.
Same URL, different associated HTML.  This creates problems for profiling,
expiration, other visited-page management facilities.

Of course, the construction of the URL being returned all depends on how you 
write your gateway... 

An implementation of highlighting using URL extensions would not create this
ambiguity.

							Gina Faber

Received on Friday, 10 March 1995 13:13:49 UTC