Re: W3C and Handle technology

At 01:10 PM 8/13/96 -0400, Daniel W. Connolly wrote:
>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.

PDF and TeX are relatively proprietary text-centric formats, invented by
individuals or corporations. MPEG and others are not that easy to change.

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

Doesn't HyTime standardize a mechanism to do that?

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

This looks like a "first class link" to me. The same mechanism should
probably be used for redirection, pointers to replicated versions, external
link maps, etc.

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

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

>> 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. Perhaps the long-term solution is to make domain
name registration faster, cheaper and easier.

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

I think the issues of moving the data and referencing it should be separate.
There will be cases where you want to replicate data but give the replicated
copy a different URL and cases where you want the same URL to refer to
documents that were not explicitly replicated using "standard" replication
schemes.

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

Perhaps "addressing" and "linking" are not the same thing and should have
their own activity pages. I think that ever since "mailto:" the Web
architecture has been attempting to describe different LINK TYPES as if they
were different ADDRESS TYPES. A link type is a relationship. An address type
is a way of accessing an object. "mailto:foo@bar.com" is not an address. It
is an instruction and an address combined.

It might be helpful to separate issues of linking from those of addressing.
I think that HyTime has already done this, but I'm no HyTime expert.

 Paul Prescod

Received on Tuesday, 13 August 1996 19:02:51 UTC