Re: W3C and Handle technology

Daniel W. Connolly (connolly@beach.w3.org)
Tue, 13 Aug 1996 13:10:07 -0400


Message-Id: <m0uqMyn-0002UdC@beach.w3.org>
To: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>, Philipp.Hoschka@w3.org
cc: www-html@w3.org, www-talk@w3.org
Subject: Re: W3C and Handle technology 
In-reply-to: Your message of "Tue, 13 Aug 1996 10:45:21 -0400."
             <1.5.4.32.19960813144521.00821580@csclub.uwaterloo.ca> 
Date: Tue, 13 Aug 1996 13:10:07 -0400
From: "Daniel W. Connolly" <connolly@beach.w3.org>

In message <1.5.4.32.19960813144521.00821580@csclub.uwaterloo.ca>, Paul Prescod
 writes:
>
> a) Links are not first class (addressable) objects. If links were
>addressable objects served by HTTP, new link formats could being treated as
>new media types are. In fact, external, first class links are almost
>required for a proper hypermedia rollout of new media types. How do you
>embed an HREF in an MPEG?

Thanks for reminding me! I completely forgot to mention on the
Addressing/Activity page that we're working on multimedia linking
stuff. Philipp Hoschka has joined W3C to work on this sort of thing:

	http://www.w3.org/pub/WWW/People/W3Cpeople.html#Hoschka

See the Audio/Video activity statement:

Audio/Video Hyperlinks
http://www.w3.org/pub/WWW/AudioVideo/Activity#anchor752870


Anyway... here's my two cents:

HREF is an HTMLism, and I wouldn't expect to see it in MPEG. "How to
you embed URLs in MPEG?" is another question: you change the MPEG
format, just like PDF, TeX, and other content formats have been
enhanced to accomodate URLs.

Another question is "how do you express a link from some region of
time-space in an MPEG to someplace else in the web?"

There isn't any standardized mechanism to do that, but I can think
of some options, among them:

	Content-Type: multipart/related; boundary="part"
	--part
	Content-Type: video/mpeg
	Content-ID: li3jlsijflisj3e@foo.com

	ASLDKFJALSJDFK
	--part
	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.

The Hyper-G system specifies some mechanisms for this sort of thing.



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

> This should probably be fixed with
first class links.

How so? I don't see the connection.


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

> This is a deficiency of the URL spec. Some
>form of DNS for object names seems required in the long term although it may
>not be feasible in the short term. (Is this related to LDAP? I can't find
>anything on W3C's site about directory services)

There are some interesting ideas regarding "web-x records" ala MX
records, to provide for service providers for HTTP to work kinda like
they do for SMTP. It provides an extra level of indirection that
might be useful, but it doesn't change anything fundamentally.


> d) Link sources cannot specify multiple resolution paths for a particular
>link target. This is an addressing (URL) problem.

Hmm... I suppose you could look at it this way. But "multiple resolution
paths" looks to me like replication, which is mentioned on the
activity statement.


> e) Link targets cannot "report" that they correspond to multiple URLs. This
>could be corrected in HTML or in a separate link data type.


We have a proposal for doing this in HTML:

http://www.w3.org/pub/WWW/MarkUp/Resource/Specification

It's mentioned on the HTML Activity statement. I suppose it's worth
mentioning on the Addressing activity statement too.

>I don't see anything at [Addressing/Activity] that suggests that these
>deficiencies are being addressed. I see lots of [good ideas] on the page,
>but no indication that W3C is planning to adopt any of them as standards, or
>promote their implementation. Is addressing on the back burner?

In a  way, addressing is  on the back burner:   URLs are pretty stable
technology.  On the  other hand, HTML  and  HTTP mechanisms to express
typed links are in development, as well as  new URL schemes to address
audio/video.

Dan