Welcome back. We need your input on the link types postings. We've been
requested to keep posting to the html-wg, so here's the latest thinking
on REL and 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.
Lee and I, and Ian Graham and I, met separately over the past week and this
is my impression of the consensus:
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.).
IMPLEMENTATION STRATEGIES:
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.
Feedback appreciated.
--
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