Re: Link style sheets [was REL and REV]

Craig Hubley (craig@passport.ca)
Fri, 12 May 95 14:26:01 EDT

> That seems to be a radical departure. It seems to me there's a design
> that's been latent in the specs for a long time, and we're just trying
> to flesh it out, not make a whole new one.
>
> When TimBL and I discussed looking at link relationships as URIs,
> the idea was to look at them as _relative_ URIs with an as-of-yet
> unspecified BASE. As to how you would resolve them, why that would
> be http, ftp, or your favorite information retrieval protocol.

All this scheme does is specify the BASE, and give you a way to override
it, either as an up-front default declaration, or in the REL value itself.

> For example, a document might look like:
>
> <html><head>
> <relbase href="http://www.w3.org/linkrels/">
> </head>
> <body>
> <h1>My Desk</h1>
>
> <p>My desk is in <a rel="container" href="../the-lab/">the MIT
> lab for computer science</a>
> </body></html>

Fine, so you are simply using HTTP to retrieve some (undefined) file.
The full name of the REL value is "http://www.w3.org/linkrels/container"
^^^^^^^^^
This is my scheme, all you have changed is that you have used an HTTP
URL instead of giving link functions their own name space. Fine. We
can fix that later if necessary. The important thing is that there be
a full name there.

> A client that wanted to know about the "container" relationship would
> dereference http://www.w3.org/linrels/container. It might discover
> a definition of container that says it's a transitive relation etc.
> For example, the ARPA knowledge sharing effort defines several ontologies
> for knowledge representation. For example, have a look at:

So you agree with me, that there is no need to specify what is at the other
end of the wire. I can see your point - if the standard does not specify
what is on the other end, then it might as well be an "http://..." URL.
Fine. Let's do that. Later we can invent URLs/URIs like "hotjava:newlink",
who cares, for now let's just be absolutely sure that the REL value is a
first class URL/URI.

> And regarding CDATA vs NAMES: just be clear that there can be more
> than one relationship in a link. The classic example is:

This is why REL values can't be simple strings, at the least they are
likely to be conjunctions of several strings, as you suggest:

> |<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>
> |
> | EMBED Embed this here when presenting it
> | PRESENT Present this whenever the source document
> | is presented

If a REL value is a URL then some way of expressing "EMBED, PRESENT" can
be at the other end of the wire.

> |Note that you can have various combinations of these, and if
> |the browser doesn't support either one, it doesn't break.

Right. Default link behavior can default to 'goto' in any case.

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