I do not suggest that we should attempt, for HTML3, anything more than
the hardwired navigation links; Only that they be given a naming scheme
that can accomodate various forms of 'looked-up' behavior later on.
Murray writes:
> Hmmm! I have been trying to follow this discussion and I have
> to admit that I am a bit confused by it. We have, at SCO, a
> browser that deals with REL=[previous|next|contents|navigate].
> It does not use Java, it is written in C. It works. For me,
> that is one good reason why REL=next is better than any scheme
> which has never been tried or tested.
Since your :
REL=next
is just an abbreviation for my:
REL="linkas:SCOnav/next"
then you have 'tried and tested' this scheme already.
It seems that no one but SCO has implemented Tim's original scheme and it
has been available for others to implement since 1989. Instead, other
vendors are implementing proprietary ways to extend the functionality
of their browsers. This seems to me to be a trend that will continue.
Also, it seems unlikely to me that future standards, or vendors who are
implementing an HTML3 standard that includes SCO's type, will stop at four
navigation-related functions. Dave's list was more extensive than that,
and other possibilities, like links to versions in other languages, or
to text-only versions, also seem likely, as the server-based alternatives
have not been implemented.
I think I have adequately explained why a facility for calling browser
patches/applets/link-type-functions ought to be generalized. Rather than
having dozens of name spaces as legal values for different attributes of
different tags, since these names actually name functions, why not create
a more consistent name space where all such functions might live ?
> Craig's arguments are very interesting, and his proposed solution
> promises to offer much greater capabilities and potential for the
> future. This potential carries a price though -- a more complex
> implementation including support for a semantics specification
> language (such as Java).
There is no need to support any specific specification/programming language.
For HTML3, I only propose(d) that the *names* of the links be URLs/URIs.
The 'support' for a semantics specification language would be limited to
this naming scheme. I outlined why we *don't* have to define what is at
the other end of the network location, in fact are better off not doing so.
The 'well known ports' solution, for instance, could be implemented by an
individual vendor to distribute patches or add-in functionality to users.
> I like to keep things simple enough so that I can understand them.
> I have to admit that I do not fully understand Craig's solution.
Here's the 'diff' between what SCO has implemented and what I propose:
-------------START PROPOSAL
1. The argument to REL becomes, instead of a string, a new URL type, the
"linkas:...". The standard or vendor which defined the link type is
named in this URL. Full names for the four SCO has implemented are:
"linkas:SCOnav/previous"
"linkas:SCOnav/next"
"linkas:SCOnav/contents"
"linkas:SCOnav/navigate"
(If you like you could name them 'TBLnav' to specifically credit Tim.
It is only important that the set of link types itself have a name)
If these are accepted as the standard then the names might become:
"linkas:HTML3nav/previous"
"linkas:HTML3nav/next"
and HTML3 documents would interpret REL values as HTML3nav by default.
2. So that authors do not have to write such long names, and so that SCO
*does not have to modify its existing HTML code at all*, we can consider
simple strings to be acceptable as REL arguments if a default prefix has
been declared (as Joe and Lee have proposed, & as is done now for HREFs).
This default prefix can be "linkas:HTML3nav/" if no tag appears. Then, if
all you are using is the standard link set, this scheme degrades to SCO's:
REL=next
is accepted as an abbreviation for:
REL="linkas:HTML3nav/next"
If SCO wants to add 15 more link types, then a declaration similar to this
(exact syntax irrelevant, the scheme laid out by Lee and Joe would be fine)
<BASE LINKREL="HTML3nav"> <! interpret as HTML3 standard link if possible >
<BASE LINKREL="SCOnewNav"> <! otherwise it is one of SCO's new ones>
appears in any document that wants to use them.
------------END PROPOSAL
The capabilities that this provides that a simple keyword string set doesn't:
- a robust name space for link types, potentially for all add-in applets etc.
- names for links that can potentially be looked up at an authoritative net
connection, to verify if the browser does or does not have the capability
- potential to distribute actual patches or extension code from that loc'n
- it avoids this scenarios which can happen with the 'simple keywords' only:
1. A vendor implements 'one or two' additional link types not in the
standard (as they always do, I think we've seen a few lists of the
possibilities), and authors use them (as they always do, look at
the popularity of the Netscape extensions). All of these names go
into the same name space, that is, the author has no way of saying,
and the browser has no way of knowing, whether WXYZ's 'embed' or
Mosaic's 'embed' was the one that the author intended to invoke.
In some cases the browser's interpretation of the link type will be
reasonable, this gets less likely as the names get more abstract.
'glossary', for instance, does that show you the meaning of a term
and leave you where you are ? Or does it dump you to another page ?
Nightmare.
2. Future versions of the standard expand the list of 'official' link
types. Some of these names conflict with the 'unofficial' usage
above. Others are suggestive of whole new lists of link types and
the problem above repeats itself, worse, as link types catch on.
3. Vendors distribute patches to deal with new link types and to
support popular 'unofficial' types. Each does so in its own
idiosyncratic fashion. There is no rhyme nor reason to the
distribution of link type (or other 'applet') definitions. Each
vendor implements its own tag(s) to specify how/where to get the
patches/extensions. Capabilities of each vendor's extension or
patching tool are available only to extend tags invented by that
vendor.
For HTML3, this proposal is identical to SCO's except for giving an
unambiguous name to each link type and a means of resolving name spaces.
By HTML4, the ability to look up and add functions would be very common.
Vendors would be able to define their own link behaviors (for examples
consider the dozens of page transitions available in HyperCard, various
devices used in CD-ROM based encyclopedias including floating footnotes,
any of the other types Dave listed) and distribute 'patches' or 'applets'
to support them. They would effectively reserve a bit of the "linkas:..."
name space, preferably starting with their vendor or language scheme name.
I see no reason to run a registry for this, as it is far less likely to
run into conflict than SCO's current scheme based on simple keyword strings.
An analogous approach can be taken to field- and form-level validation, new
screen widgets, or any other application- or platform-specific function that
might be defined after distribution of the browser.
--
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