Re: Don't put descriptive info in a URI, only identifying info

>>There is no difference here between HTTP and broadcast, other than the
>>fact that the 'http' URL contains a hostname.  The philosophical properties
>>of naming are the same.
>
>Here is where we may diverge somewhat.  Taking the example of a broadcast
>HTML document, the problem is in fully specifying it's "location".  For
>example, let's say this document will be part of a broadcast stream and it
>is known in advance that it will be sent at 1:00am tonight on some stream,
>and at no other time and no other stream.

You can either identify the resource that is represented by the document
or you can identify the resource that is a period on a broadcast stream.
Those are two different resources, even when they map to the same
representation.  Honestly, there is zero difference between allocating
the TV namespace and allocating the HTTP namespace after the hostname --
they both identify resources without any real bound on the scope of
resources that might be identified.

>Is it appropriate to put this broadcast time (and stream specifics) in the
>URL?  Or, should the URL simply be an opaque pointer to the object, and
>broadcast time (and stream specifics) be communicated to the recipient by
>some other means?  The former would permit, with only the URL, to locate
>and acquire the object (albeit somewhat delayed in delivery).  The latter
>case would *require* that a document cache be maintained (which is useful
>anyway for other purposes) and it would either get a cache hit or not at
>any given point in time - no acquisition could occur with the URL alone,
>and no feeback to the user could be provided saying that "I don't have it
>now, but I will at 1:01am".

You want both, but not in the same URL.  Even if you use strict name-based
(not necessarily opaque) semantics for one URI, you will still need some
other form of identifier(s) for identifying the set of broadcast streams.
The key point that Dan was arguing is that you don't want to put all of
it in a single URI, since the URI should only contain the identification
part and not general information about the resource.

....Roy

Received on Tuesday, 22 December 1998 20:32:06 UTC