Re: on Why= with keyword REV= et al

Craig Hubley (craig@passport.ca)
Tue, 16 May 95 04:18:05 EDT

> On Thu, 4 May 1995, Craig Hubley wrote:
>
> > So, this HTML fragment:
> >
> > <A HREF="http://..." WHY="legal/precedent">
> >
> > with WHY OFF (as now) appears as:
> > ...In *Jones vs. Jones* the Court had assumed...
> > with WHY ON (default?) appears as:
> > ...In *(legal/precedent) Jones vs. Jones* the Court had assumed...
> >
> > In either case, if the user hovers over the link they see "to legal/precedent:
> > [the destination URL]". In either case the WHY is reported just as written.
>
> WHY= as a concept holds real appeal to me. BUT I would propose that
> it be a tag not an attribute. Only allowed inside an anchor. By
> making it a tag, I believe all of the characteristics Craig proposes
> could be retained with additional possiblities for richer content.
> One could get carried away but I could see a MAC balloon pop-up with
> a few lines describing the relationship. Use of emphasis markup. Etc.

NO! The whole point was to have a short well-defined list of
semantically- consistent WHY values that would converge towards some sort
of standard usage. WHY was not intended to guide presentation in more than
a rudimentary way, and it now seems we prefer to use REL for this purpose.

I can generate a map of document links where WHY="legal/precedent" (or,
in our current usage, REL=legal-precedent ). I can also generate a map of
document links where a specific popup function is called, but that is less
than useless for navigation purposes.

There are probably 200 ways to visually represent or explain the implications
of a legal precedent. That's fine. But there has to be only one way to say
what it is.

> And let us not forget on of the very early requests which started us
> down this path ... the ability to invoke browser function from
> arbitrary points within a document. I keep seeing suggestions about
> adding stuff to the browser button bar dynamically. Useful yes, but
> not the original point which is strongly reinforced as one surfs
> the current web. The browser button bar needs to move selectively
> and dynamically into document text.

We are currently specifying some REL values with clear browser behavior
implications - I posted separately on this. But the problem of how to
let authors define their own relationships that persist, independent of
which browser presentation functions are defined/invoked/standardized,
will not go away. It is the only way to generate meaningful web maps.

The fact that so many people confuse these issues makes me think that
we should follow Ian's suggestion, add an ACTION attribute to the LINK
and A tags, and separate once and for all the *author's idea of the
relationship* from the *browser's visual presentation of that same
relationship*. There is value in keeping the two together, but with
no universal mechanism for binding several presentation functions to
the same abstract relationship, it's probably hopeless.

The main objective is to avoid a Web where links are differentiated by
browser behavior, rather than by the semantic purpose of the link in
the context of the document or corpus. I think everyone can see how
the latter would be very difficult to meaningfully index, crop, or map.

-- 
Craig Hubley                Business that runs on knowledge
Craig Hubley & Associates   needs software that runs on the net
mailto:craig@hubley.com     416-778-6136    416-778-1965 FAX
Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5