RE: Qualities of URLs and resources

Larry Masinter writes:
> Neither of these notations captures content negotiation, and it isn't
> OK to remove 't'. The whole *point* is to understand what are
> the things that are stable over time and which things can change, and how.

Well, it was my intent that the set of values (V1, V2, ... Vn) represent
variants of the resource at a particular instant in time, and hence I
thought I was modeling content negotiated resources.  But, as Geoff Clemm
points out, both Roy and I did omit the Accept headers as an input to the
RMap function.

> If you just look 'at an instant' then there's no meaningful way
> of distinguishing URLs from resources, and collapsing -UMap->.

I'm not sure what you mean here, since I believe it is meaningful to
discuss, conceptually, the difference between URI mappings and Resource
mappings at a particular instant.  Certainly it would take more than an
instant for a client to *operationally* determine a resource has multiple
URI mappings.  That said, I'm more than happy to chuck time back in there.
It does have the benefit that it permits a formal description of the
operation of bind on URIs.

I'll formall define bind's effect on URIs as:

URIbindset = bind(targetURI, collectionURI, segement, t)

The bind function takes as input a URI of the resource being bound-to, the
URI of the collection resource where the new binding will reside, a URI
segment giving the new name of the binding in the collection, and the
current time.  The bind function produces as output, the set of URIs that
can now be used to access the resource that was identified by targetURI at
time t.

Now, the change caused by bind to the URI mapping function for a resource R
can be described as:

UMap(t+ epsilon) = UMap(t) + bind(targetURI, collectionURI, segment, t)

Where epsilon is the time required to execute the bind method, and UMap is
the URI mapping function for the resource identified by the target URI.
(Hmm, don't like the fact that the resource is now implicit here ... perhaps
I really want to use the inverse function UMap-1(UMap(targetURI, t)), that
is the set of URIs that identify the resource that is mapped to the
targetURI.  This would look like:

UMap-1(UMap(targetURI, t), t+epsilon) = UMap-1(UMap(targetURI,t)) +
bind(targetURI, collectionURI, segment, t)

Which is ugly, but perhaps more precise.

> I'm guessing you want to make UMap vary more slowly and only with
> explicit operations (BIND and UNBIND) while RMap encompases all of
> the content negotiation & time varying behavior of resources without
> having any explicit operation modify the mapping.

I agree with this, although I'll pick the nit that UMap doesn't necessarily
have to vary more slowly than RMap, especially if RMap represents a static
resource.

- Jim

Received on Thursday, 10 February 2000 21:14:01 UTC