LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives

HTML-WG Archives

HTML-WG Archives


Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font


Join or Leave HTML-WG
Reply | Post New Message
Search Archives

Subject: Re: REL="LinkAs:...", supporting link type names as a full URL/URI
From: [log in to unmask] (Craig Hubley)
Reply-To:[log in to unmask]
Date:Wed, 10 May 95 17:37:27 EDT

text/plain (65 lines)

> Just a quick note --
> Craig's ``LinkAs'' proposal does not represent a consensus, as this mail is
> the first I heard of it.

Yes, I should have made this clear.  Lee favors the "X-xxx" scheme for any
extension beyond immediately standardized browser behavior.  The "linkas:..."
is my attempt to address the concerns that Lee and Ian had expressed.

I am putting this up for discussion, it is not a proposal as such yet.  Sorry
if anyone took it as such.
> Craig, do keep in mind that
> [1] there is _already_ a URL/URI associated with the link.  We don't need
>     another one.

I disagree.  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.

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 behavior
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...

> [2] There is _already_ software using the existing scheme

To my knowledge, only SCO's browser has done so.  All they would have to 
change is that REL="linkas:next" rather than REL=next, etc.,  If they like
they can continue to support REL=next as a synonym for REL="linkas:next".
Additional implementation work is minimal, just accept "linkas:next" as a
synonym for "next", etc.  This seems like just a couple hours' work to me.  

> [3] I am _not_ proposing a ``new namespace''.  What I am proposing is that
>     we suggest that people continue doing *exactly* what they have been doing,
>     and that we use Tim's 1989 draft document as a basis.

But no none has actually *been* doing this.  Tim's document has been ignored,
except at SCO.  This suggests to me that there is something wrong with it.  
You are right, though, it was Tim that proposed the 'new namespace' in 1989,
and the nonexistent response (except at SCO) suggests that this proposal was
rejected.  Why revive it, when it is so easy to do something more consistent
with recent innovations (like the "mailto:...") that have been warmly received,
and provides a more consistent way to support shared behavior that may or may
not be implemented directly in the browser ?  This doesn't make sense to me.

Tim's 1989 proposal is dead.  From what I can see, it died for a reason, and
the separate, non-URL, name space and binding mechanism for link types was 
probably it.
Craig Hubley                Business that runs on knowledge
Craig Hubley & Associates   needs software that runs on the net
mailto:[log in to unmask]     416-778-6136    416-778-1965 FAX
Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5

Back to: Top of Message | Previous Page | Main HTML-WG Page



CataList Email List Search Powered by the LISTSERV Email List Manager