From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>

Date: Thu, 10 Feb 2000 08:53:49 -0500

Message-Id: <10002101353.AA04843@tantalum>

To: w3c-dist-auth@w3.org

Date: Thu, 10 Feb 2000 08:53:49 -0500

Message-Id: <10002101353.AA04843@tantalum>

To: w3c-dist-auth@w3.org

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

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:01:21 UTC
*