Subject: RE: Qualities of URLs and Resources (take 2)

From: "Fielding, Roy" <[email-masked]>
Date: Fri, 5 May 2000 12:22:02 -0700

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

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.

The above is how internal redirects are handled today, which are
effectively the same thing as bindings but without a standard for
remote configuration authoring.  The only real difference between a
binding and an HTTP gateway is the location of the target.

> 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 is equivalent to a remote authoring interface to the configuration
files used by mod_rewrite (an Apache module), though with a restricted
set of features in order to reduce complexity.

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

Cheers,

Roy T. Fielding, Chairman, The Apache Software Foundation (www.apache.org)
                 Chief Scientist, eBuilt, Inc.            (www.ebuilt.com)

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sat, 6 May 2000 16:52:30 -0400 (EDT)

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" <[email-masked]>

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

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

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.

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

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

   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