Re: Qualities of URLs and Resources (take 2)

It does look we're converging.  Just a few comments (to see if I set
off any tripwires that Jim managed to avoid :-).  Since we're basing
the "versioned collection" semantics on the bindings semantics, I want
to make sure we're in synch.

   From: "Fielding, Roy" <fielding@eBuilt.com>

   > Using Roy's notation, a resource's mapping functions and values can be
   > represented as: 
   > 
   >  {U,t} -RMap-> {V1, V2, ... Vm} 
   > 
   > A binding resource's mapping function and values can be 
   > represented as: 
   > 
   >  {U1,t} -RMap-> {V1, V2, ... Vm} 
   >               >  | 
   >              /   | 
   >          RMap    | This mapping function is derived from the 
   >  {U2,t} /        | definition of the abstract binding resource 
   > 

   > In this case, by definition of the binding resource, the set of
   > values is the same, though the mapping function is different.

   What is the advantage of the above versus: 

		  -> {U1,t} -RMap-> {V1, V2, ... Vm} 
		 / 
		/ 
	     RMap     | This mapping function is derived from the 
     {U2,t}- /        | definition of the abstract binding resource> 

I believe what Jim wants to do in his later diagram is to emphasize
that there are two different classes of URI's, that participate in two
different kinds of mappings.  The first (the "UMap") is captured by
the union of the "states" of a set of collection resources, and is
modified by the BIND and UNBIND requests.  The second (the "RMap") is
not affected by the BIND and UNBIND requests (and is not necessarily
even visible to the client).  So in the immediately preceding diagram,
the "RMap" between {U1,t} and {V1, ..., Vm} is actually a "UMap".

   This is essentially requiring that, for all things that can be bound, 
   there exists at least one URI representing the target of that binding. 
   Note that this can be a non-public identifier, such as a file URL, 
   that may be ony accessible from within the server. 

Sounds right.

   > But, this has the difficulty that no identifier exists for the
   > set of values. This identifier is useful, since it allows the
   > construction of URL to identifier pairs.  In cases where the set
   > of values has only one member, and this member can be modified
   > with a PUT or PROPPATCH, these pairs allow a client to determine
   > a priori whether the effect of an action on one URL will be
   > visible via another. This capability is useful in a number of
   > authoring situations.

   Ummm, sometimes.  Because resource implementations have all the
   complexity of a turing machine, there is no way to ensure that
   changes in one will not have an effect on others, particularly
   since a resource on one machine may be defined in terms of
   resources on other machines.

   What you are creating is a situation in which some well-defined
   dependencies between resources can be discovered and manipulated by
   the client, which may be a good thing for some authoring situations
   *provided* that the client never assumes it knows the complete set
   of dependencies.  It is impossible to require the server to manage
   all of the dependencies, since no single server can know of all the
   dependencies.

This all sounds right.  The latest drafts of the binding semantics
don't try to say anything beyond how the various operations affect the
bind relationships created and removed by BIND and UNBIND.

   > Previously, I wrote: 
   > 
   >  {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm} 
   > 
   > To express going from a URL to the set of values.  I still like
   > this diagram, but calling the middle item a "resource" is a
   > mistake, since a resource is an *abstraction*.  The middle item
   > is really an identifier for the set of values, what I'll term a
   > resource implementation identifier

   > (RII).  That is, it does not identify the resource, only a
   > specific implementation of the resource in the form of the
   > resource mapping function RMap, and the set of values. Rewriting
   > it yields:

   >                                  resource 
   > {URI1, URI2, ... URIn} -UMap-> implementation -RMap-> {V1, V2, ... Vm}
   >                                 identifier 
   > 
   >                                | 
   >   <-- affected by bindings --- | ---affected by resource's defintion --> 
   >                                | 

   > In this diagram, the abstract concept of the resource has been
   > used to define the resource mapping function, RMap, and the set
   > of values, {V1, V2, ... Vm}, and the RII uniquely identifies this
   > (RMap, Value set) pair.  That is, it uniquely identifies this
   > specific implementation of the abstract resource. A single
   > binding can be viewed as an element of the UMap set, that is, a
   > specific (URI, RII) pair. Thus, the effect of the bindings
   > specification is to manage the UMap function, as specified as a
   > mapping from URIs to the RII.  By introducing the notion of the
   > resource implementation identifier, it is possible to introduce
   > bindings without having to redefine the notion of a resource,
   > without having to break the resource abstraction layer, and
   > without having to introduce a new kind of resource (a binding
   > resource), while still providing clients with a unique identifier
   > for the *implementation* of the resource.
   > 
   > So, Roy, did I set off any mental trip wires this time? :-) 

   Well, assuming that the RII is just another URI, that is fine.  In
   terms of how the abstraction works, you are right on the mark.

Note that in the binding spec, we allow a server to expose the "RII"
in the DAV:urn property, so this is consistent with Roy's description.

Cheers,
Geoff

Received on Saturday, 6 May 2000 16:52:42 UTC