The W3C <a href="http://dig.csail.mit.edu/breadcrumbs/comment/reply/124">work to define</a> typed links tends to focus on the problem of defining a global list of names.

Craig Hubley suggests instead "to start thinking of link types much more as traditional types as defined in programming languages with non-global scopes." The discourse about this dating back to 1995, notes that while "global types are of much use on the public web, to restrict the use of types on intranets or private webs may be unwise, especially if the namespace gets crowded out. The 1990s proposals to set lists of standard link types failed, I think in part for this lack of flexibility."

"A link is a function with behavior, and entities to be involved. It is usually best to have only one means of binding objects in a function call. The URL/URI is already there. I am proposing we use it to bind other objects. The alternative is to impose multiple binding schemes to resolve one function. This has no hope in hell of being supported outside HTML, as it will (rightly) be seen as baroque." URIs are good enough.

"Right now we can specify an entity with no arguments and only default behavior (a standard goto link), 'flaky' server behavior with no implied entity (cgi-bin scripts), or one form of complex browser behavior with an argument in its URL
(mailto links). Now we are presented with several new browser behaviors to be supported. We either unify this mess under one binding scheme where behaviour and arguments are in a single predictable place, or let HTML become another baroque, unimplemented, pseudo-standard, where every time someone wanted to add something new, they invented a new name space for it..." Ten years later, this had happened a few times.

The original proposal was, according to Hubley "ultimately rejected by the SCO people in favour of simply repeating their own limited scheme as a draft RFC that predictably failed".

A linkas: protocol is one in which the link type is simply a (local, private or global) DNS address. Any fixed list of names, including any embedded in the browser (e.g. "linkas:opera/feed") is thus an optimization. Browsers could be smart enough to know the difference between the expected behaviours and to copy them. When standards are agreed, you can get less proprietary names (e.g. "linkas:W3C/feed") or eventually even a short English word as you seem to be proposing: (e.g. "linkas:feed"). Hubley argues that to "cut off the process of evolution too early and to fail to support link types that are arbitrarily defined by the user or user organization or affiliate, is a serious mistake. As in 1995 it'll likely just fail" and that "weak, bottom-up ontologies, have to compete, before strong ones can emerge. It's not any easier than assigning meaning to words in the dictionary."

His original proposal defined "how link types fill the 'dead zone' between the default 'goto' behavior of unmarked links, the 'what-th'?' behavior of cgi-bin scripts, and these more standardized and predictable behaviors/names we seem to need."

"1. We want to support the implementation effort that SCO has already done.
SCO's tags are likely the best starting point for a list of types that
are actually unambiguous instructions to the browser itself. However it
seems that this is not the only kind of useful link type. We might support
the additional relationships under a single extensible name scheme / URI
as was done with 'mailto' (e.g "LinkAs:goto" "linkas:next" "linkas:toc"
"linkas:embed", "linkas:floatingfootnote", "linkas:author", etc., etc.).

There seems to be no need to standardize behaviors not built into browsers,
beyond recognizing the name identity (critical for generating web maps etc.)
Default REL value is "linkas:goto", scripts fit too: "linkas:cgi-result/.."
or whatever. Lee proposed a slightly different, but non-URL/URI, scheme
with the same semantics, but this creates another name space that does not
seem necessary, and does not have the potential to support lookup of names
over the network (if unknown). I think links are being added as URIs anyway.

Several issues in this, but 'linkas' provides a route for future expansion
and lets browsers decide whether to implement, look up, or default the
behavior to a simple 'goto' (if they can find no definition for it). It
clarifies that this is the name of a specific (browser-executed) behavior.
It fits with the URL/URI name scheme (so we don't create a new name space)
and supports the legacy behavior nicely. Another attribute may be needed
to let users override the link type name with one in their native language
(or with an icon). The anchor text is the name of the *link* not its type.
The name of the type defaults to the behavior (e.g. "linkas:next" links
have the type name "next", but this can be overridden to "Next Page" etc.).

Hardwiring various "linkas" behaviors into browsers does nothing to
cut the author's work unless s/he can be certain that the browser that the
user has under them, will interpret it correctly. Otherwise they need to
write scripts anyway (to support all the browsers that do not interpret a
"linkas:next" correctly). This gains nobody anything except in specialized
environments where you can guarantee that the user will use a given browser.

One approach to getting this done is to encourage browser developers to
implement useful behaviors of their own (e.g. "linkas:buywithcreditcard")
under the "linkas" scheme, just to ensure that they support it at all, then
slowly standardize the practices so that they become predictable to authors.
This would parallel the work you've done at SCO.

2. There are other clearly-defined sets of link type relationships around.
NNTP and SMTP fields, already browsed directly by Netscape, Hypermail,
etc., are mostly 'direct references' to other URLs. They provide new
link type *names* but not semantics (e.g. a link from a news article up
to the newsgroup can be considered a "linkas:toc", one to the next article
in a thread a "linkas:next", etc.). This needs to be documented as well.

3. 'Next', 'Back', 'Previous', etc., all have arbitrary definitions that do not
seem to have a universal meaning (e.g. chronological or spatial ? - to me
'previous' always means time whereas 'back' can mean time or spatial move,
Ian Graham says he sees 'previous' as meaning 'page before' despite what
the dictionary may say). To avoid these semantic battles I think it is
best to find words that directly describe the browser behaviors (e.g.
"linkas:embed" "linkas:floatingwindow" rather than "linkas:footnote" since
the latter could have several different semantics to different authors/users
and the lookup for unsupported types is easy enough).

4. links to the same document in a different language, or in text-only form,
may be useful but there is some doubt as to whether the provisions in HTTP
to tell the server about user and browser capabilities will be implemented.
I favor supporting these as link types "linkas:inlanguage/francais",
"linkas:forbrowser/text-only", etc... because I don't think the servers
will implement browser capability negotiation in the near future.

5. The "linkas:..." scheme generalizes the notion of the behavior of a link.
The link anchor becomes more like a proper function call, which does more
than just the 'goto' and 'lookup' options supported in the original HTML.
This function can be considered to be a method call on an object (the HTML
document currently being viewed) that takes a couple of potential arguments,
including a link *type* and *destination*. Arbitrary arguments could be
sent as for cgi-bin scripts. Ultimately cgi-bin scripts can be resources
shared through the "linkas:cgi/..." mechanism, rather than server-specific
hacks, whose semantics are unknown to the browser and user until invoked.

Among other things this would help deal with the 'filled in form' problem.
"linkas:submitform" would alert browsers that this page was a filled form.
Its state can then be preserved so that the use may return to 'fix it' etc."