Subject: Qualities of URLs and resources

From: Jim Whitehead <[email-masked]>
Date: Wed, 9 Feb 2000 14:29:08 -0800

Roy Fielding writes, in his post originally titled,
"draft-ietf-webdav-binding-protocol-02"
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0125.html>:
> > URI Mapping
> >      A relation between an absolute URI and a resource.  For an
> >      absolute URI U and the resource it identifies R, the URI mapping
> >      can be thought of as (U => R).  Since a resource can represent
> >      items that are not network retrievable, as well as those that are,
> >      it is possible for a resource to have zero, one, or many URI
> >      mappings. Mapping a resource to an "http" scheme URL makes it
> >      possible to submit HTTP protocol requests to the resource using
> >      the URL.
>
> Actually, it is more like ({U,t} -R-> {V1, V2, ...}), where t is the
> current time, R is the resource, -R-> is a mapping function that has
> been implemented according to the semantics of resource R), and the range
> is a set of values representing that resource at time t.

OK, so this notation makes it much more clear that a resource is a mapping
function.  However, if we just call the mapping function "R", this allows us
to express that multiple URI can be associated with the same mapping
function.  That is, the binding spec. is based on the mapping from URI to R
being many to one.  From your post, I think you believe it is one to one.
If so, this is at the heart of our disagreement.

So, using your notation, I would re-write the full mapping as:

 {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm}

Where UMap is the URI to resource mapping function, and RMap is the resource
to value mapping function.  I omit time since it's really tangential to our
discussion, assuming that the entire set of mappings occurs at a given time
t.  In this view, the term "resource" as used in RFC 2396 is both the output
of the UMap function, and the RMap mapping function, but *not* the set of
values.

As near as I can tell, this view is entirely consistent with the definition
of resource given in RFC 2396:

      Resource
         A resource can be anything that has identity.  Familiar
         examples include an electronic document, an image, a service
         (e.g., "today's weather report for Los Angeles"), and a
         collection of other resources.  Not all resources are network
         "retrievable"; e.g., human beings, corporations, and bound
         books in a library can also be considered resources.
         The resource is the conceptual mapping to an entity or set of
         entities, not necessarily the entity which corresponds to that
         mapping at any particular instance in time.  Thus, a resource
         can remain constant even when its content---the entities to
         which it currently corresponds---changes over time, provided
         that the conceptual mapping is not changed in the process.

There is nothing in RFC 2396 that either states or requires the URI to
resource mapping be one to one.  A resource can still be a mapping, even if
it has multiple URIs to it.

- Jim

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 9 Feb 2000 20:46:30 -0800

> t.

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.

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

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 10 Feb 2000 08:53:49 -0500

It's not that time or content negotiation aren't important,
but just that including these aspects of the RMap function
was not relevant to the point being made.  Perhaps modifying
the notation will help clarify.

Let's use the notation:
   R:{U,T}->V 
instead of:
   {U,t} -R-> {V1, V2, ...}
You can expand this to include content negotiation by adding
another argument to the R function, i.e. R:{U,T,C}->V.
(U is the set of URI's, T is the set of points in time,
C is the set of content headers, and V is the set of values,
where each value is an entity body and a set of properties).

Jim's point is that a "resource" is a function RMap:{T,C}->V.
There are more arguments to the RMap function, i.e. the request
body and all the other headers, but that doesn't affect the discussion.
Let's let RES be the set of all such functions (i.e. each member of
RES is some function that maps time and a content header into a
value).  There is another function, which Jim calls UMap, which maps
URI's into resources, i.e. UMap:U->RES.

In other (possibly more obscure :-) words, UMap is the result of
currying the URI's out of the R function, a resource is a member
of the range of UMap.

The BIND method gives you control over the UMap function (as do MOVE
and DELETE).

The semantics of the DAV:resourceid property is that it is not affected
by either time or content headers (or any other header).  I.e.:
 for-all RMap in RES
    if RMap supports the BIND method then
       there-exists a string, s, such that
          for-all t,c in T,c
             the DAV:resoureid property of RMap(t,c) is equal to s.

Cheers,
Geoff

   Roy:

   Jim:
   So, using your notation, I would re-write the full mapping as:
   {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm}
   Where UMap is the URI to resource mapping function, and RMap is the
   resource to value mapping function.  I omit time since it's really
   tangential to our discussion, assuming that the entire set of mappings
   occurs at a given time t.

   From: "Larry Masinter" <[email-masked]>
   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.
   If you just look 'at an instant' then there's no meaningful way of
   distinguishing URLs from resources, and collapsing -UMap->. 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.

---

From: Jim Whitehead <[email-masked]>
Date: Thu, 10 Feb 2000 18:09:18 -0800

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

> 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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 10 Feb 2000 21:36:03 -0800

>If so, this is at the heart of our disagreement.

No.  I've said many times that a resource can have many identifiers.
In other words, you can have two different URI that *mean* the same
thing when used to access a server.  But, you can also have two URI
that result in the same mechanism being used upon access to the server,
and yet those two URI point to two different resources because they
don't mean the same thing.

What the bindings spec gets wrong is that at no time whatsoever
does the server or the client know the meaning of the URI, and therefore
cannot know whether a new binding represents a new identifier for
the resource or a new identifier for a *new* resource that just
happens to share the same implementation mechanism at that time.
That's because the resource is the concept, not the representation
of that concept and not the URI-to-representation mapping mechanism
on the server.

There are no resources on the server; just mechanisms that supply
answers across an abstract interface defined by resources.
The reason the protocol talks about these things as resources
is because the protocol is not allowed to define the mechanisms
on either side of the abstract interface.

It may seem odd, but this is the essence of what makes the Web work
across so many different implementations.

The reason I said that the bindings spec should just *treat* the
interface as if the URI:R is one to one is because that way the
issues of maintaining the semantic mapping are left to the author,
while the interface, which is always manipulating resources, has the
effect of manipulating URI mappings.

In other words, if you just remove *everything* in the bindings spec
that defines an implementation, including all of the attempts at defining
bindings as being something other than resources, then what you will end
up with is a very simple protocol for manipulating URI mappings on
remote servers.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 12 Feb 2000 18:23:18 -0800

>points out, both Roy and I did omit the Accept headers as an input to the

I omitted them because they do not modify the resource mapping.  If we
talk instead about the content selection process, determining which V(i)
to use as the representation of that resource at time t, then yes you
would have to include all aspects of the request, including its context
(lower-layer protocol things like IP address, SSL identity, etc.).

....Roy