Re: Qualities of URLs and resources

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

   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" <LM@att.com>
   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.

Received on Thursday, 10 February 2000 09:04:10 UTC