RE: Qualities of URLs and Resources (take 2)

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