<resouce>, links, and addresses [was: W3C and Handle technology ]

In message <1.5.4.32.19960813230044.0081a0c8@csclub.uwaterloo.ca>, Paul Prescod
 writes:
>>	Content-Type: text/html
>>
>>	<resource
>>		 href="cid:li3jlsijflisj3e@foo.com#frames=100-200;x=12;y=20">
>>		<!-- ^^^ source of link ^^^ -->
>>	  <link href="http://foo.com/"> <!-- <- destination of link
>>	</resource>
>>
>>	--part
>>
>>i.e. an associated HTML document that describes the link. I'm sure
>>there are more straightforward ways to represent links than
>>HTML <resource> elements, but they do suffice.
>
>This looks like a "first class link" to me.

Hmmm... my working definition of "first class" is "addressable."  If
the <resource> element above had an ID=xyz attribute, and it were in
some document whose address was ABC, then I can see that you could
call it a first class link, since its address would be ABC#xyz.

> The same mechanism should
>probably be used for redirection, pointers to replicated versions, external
>link maps, etc.

Yup. That's the idea behind <resource>.

For folks who lost track of the thread over the last month, please
see:
	http://www.w3.org/pub/WWW/MarkUp/Relationships
and:
	http://www.w3.org/pub/WWW/MarkUp/Resource/Specification

>>> b) There is no standardized way for a content provider to set up a browser
>>>and server independant address redirect.
>>
>>The HTTP redirect mechanism has been standard for some time now. Are
>>you talking about standard administration mechanisms? We don't generally
>>get into that sort of thing. We specify the interfaces, and let the
>>market compete on the components.
>
>I'm talking about a redirection _data format_. A "file" that a content
>provider can move from ISP to ISP no matter what software they are using
>which ALWAYS behaves as a redirection, in the same way that an <A> element
>in an HTML file always behaves like an anchor.

Yes. TimBL wrote up the <resource> spec with this in mind.

>>> This should probably be fixed with
>>first class links.
>>
>>How so? I don't see the connection.
>
>With first class links, you could specify a redirection as a link target
>that is also a link source "object" of type "redirect-permanent" or
>"redirect-temporary".

Yes. Murray Malone wrote about that in his draft. "pointer" links
or something like that.

The question in my mind is: should it work like C, where
the amount of indirection is specified at the source (*p vs **p vs...)
or HyTime, where the indirection is specified at the destinatio
(i.e. if A->B is a link and B is marked specially, link traversal
continues through B to C, and if that's marked special, ...)


>>> c) URLs are flexible, but as long as they must contain a domain name, they
>>>are tied to a particular machine.
>>
>>Not true. Internet domains are not "tied to a particular machine."
>>www.w3.org is several machines, some in the US, and some in Europe.
>>The underlying machines change, move, etc., but the name stays
>>the same.
>
>I suppose that's true. But in practice, the cost of internic registration of
>a domain name means that "small players" (usually individuals) are
>restricted to their service provider's domain name. As long as domain names
>cost money, there should be some way of having URLs that are independant of
>domain names. Anyhow, that's Star Trekish stuff. It probably won't get
>solved in the short run.

[Here we go again. This is "the URN myth"]

It won't get solved because it's not a technical problem. It's an
intrinsic property of names: they're valuable, and therefore they're
likely to cost money. They also require maintenance, or they
lose their value.

> Perhaps the long-term solution is to make domain
>name registration faster, cheaper and easier.

Optimizatios of all aspects of DNS are worth looking into.  But the
basic mechanism is sound. It's not the only sound mechanism
(hierarchical administrative naming) , but it's one of the few (the
others being things like DCE UUIDs, but resolution of that sort of
thing is tricky.)

>Perhaps "addressing" and "linking" are not the same thing

Agreed.

> and should have
>their own activity pages.

Only if there's something to say/do about linking. I suspect
there is, but I dunno.

> I think that ever since "mailto:" the Web
>architecture has been attempting to describe different LINK TYPES as if they
>were different ADDRESS TYPES.

mailto: is just misnamed. It should have been called mailbox:, which
makes sense as an address. But even if it were spelled rose:, it
would still work just fine as an address.

> A link type is a relationship.

Yes.

> An address type
>is a way of accessing an object.

Nope. A method is a way of accessing an object. An address type is
just a namespace -- a way to tell one set of names from another.

> "mailto:foo@bar.com" is not an address.

Try thinking of it as mailbox:foo@bar.com.

> It
>is an instruction and an address combined.

No, it's just that the natural way to activate a link to a mailbox is
to begin composing a message destined for that mailbox (i.e. POST)
rather than fetching and displaying a document.

Hmm... it would be an interesting twist if a web browser would
realize that for me, activating a link to mailto:connolly@w3.org
should bring up a browser on my inbox, rather than bringing
up a compose window.

Dan

Received on Tuesday, 3 September 1996 01:15:34 UTC