Yes, we seem to agree that link semantics need to live somewhere
other than in the browser source code. HotJava etc., certainly
point very strongly in this direction.
> > unless they explicitly request it by specifying a link
> > with relation LINKREL and an HREF which points to an object
> > specifying a set of semantics for a particular set of
> > link relation names.
I will refer to a URL/URN/URI as 'URx'...
This 'HREF which points to an object specifying a set of semantics for
a particular set of link relation names' is exactly my "linkas:..." URx
except that I wanted one URL per link relation name, not per 'set' since
URxs can naturally group the objects with a hierarchy.
> Of course, this doesn't handle the case where one adds a keyword to
> a set of semantics.
This is *why* I specified one URx, one link relation name, and not per set.
The browser knows where to look for the semantics, and if there is an extra
link defined there it will know.
> There is no general solution to this that I can see, apart from suggesting
Isn't it a general solution to allow a dynamic lookup ?
> I think I prefer a new and separate attribute, because then one can
> give Anchors a link role as well as LINKs in the HEADer, and can override
> the link nameset on a per-anchor basis.
Override the link nameset on a per-anchor basis is the "linkas:..." URx as
I proposed it. If you want it to be a different attribute than REL, fine.
But it's not necessary. REL=next in the anchor with LINKREL=LINK SET in
the header is semantically identical to REL="linkas:LINK_SET/next" and you
have your per-anchor override. Next question.
> Having said that, I am also thinking about how to write the spec for
> HoTMetaL, which doesn't have any HTTP support and doesn't itself follow
> URLs at all. In many cases, it can't, as a lot of people use it on
> stand-alone systems and copy files to the WWW server later -- e.g. a
> portable PC.
This is a common issue. Just because we specified the name in URx form
does *not* mean that the behavior must be retrievd using HTTP - "mailto:..."
links, for instance, do not - the behavior remains localized in the browser.
> This means that we'll end up hard-wiring the link set and the
> link terms that are special, or at least put them in a config file,
> for a pop-up list.
Probably. But the browser needs to hardwire the 'HTML3 standard link types'
anyway. It's only for future practice and easy re-integration of browser-
specific behavior into the naming scheme, that we really need the URx form.
> If we follow this route, though, I think we *must* define what is at
> the other end of the URL, so that software can at least determine
> automatically what the keywords are and where they came from, can
> flag incorrect ones, warn about multiple (possibly conflicting) cheeses,
> offer users a choice of keywords to insert, and possibly display only
> links of a certain type in a visualiser.
For now (HTML3) we probably only need to have a file that lists synonyms,
i.e. if you specify REL="linkas:www.lawyers.com/case_law_links/precedent"
(no matter if you hardwire this or say REL=precedent with the prefix set
as we are discussing), then you find a file at www.lawyers.com/case_law_links/
precedent that lists the browser behaviors desired in order of preference
(e.g. underlined GOTO w/ a popup abstract). If you like you can optimize the
lookup up a set of links by allowing www.lawyers.com/case_law_links/index.rel
to list all of the synonyms for the 'case law links'.
More sophisticated behavior as supported by HotJava etc...
> One way to do this would be to have the other end contain a list of anchors,
> each with a REV tag for the keyword they are defining, and optionally
> pointing to an actual definition, e.g. JAVA code.
Hmm, this is looking like a consensus again. The 'simple synonym file' can
grow into this nicely.
> Obviously an actual browser would not do all this indirection, or even
> Netscape would need to get their graphics designers to change the hourglass
> icon to a calendar icon :-)
Ideally it would cache every link behavior that it had ever seen somewhere.
> If I were less tir'd I'd try to discuss why & whether all this indirection
> is actually useful, and to whom. I still think we have not seen a good,
> practical, down-to-earth justification for changing Tim's original scheme.
How about: "it didn't catch on, and HotJava did"... ? In 1995 we need a
way to re-integrate all these wacky ways for browsers to share behavior,
since otherwise we will be stuck with a bunch of vendor-specific 'standards'.
> That doesn't mean that there isn't one. It means that I think the
> theoretical reasons are not strong enough, as there are pragmatic counter-
> arguments for them.
I have not yet seen one reason why REL=next is better than REL="linkas:next",
given that both would be hardwired into the browser, and there are a number
of well-defined ways to extend the latter to handle complex browser behavior.
-- 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