Re: Client Option for Strong References

>A reference can be referring to one of two things.
>
>A. It is referring to a location in the URL namespace (consequentially
>referring whatever resource is available there)
>B. It is referring to a specific resource (consequentially it should follow
>that resource as it moves)

I don't recommend this line of reasoning.  First of all, there are no
locations in the http namespace, only locators.  An individual server
may map some part of its namespace to a filesystem, which in turn maps
to the equivalent of an inode that can be mapped into a disk location,
but those underlying mechanisms provide a means of associating a resource
to a set of representations rather than identifying the resource itself.
Many different resources could map to the same representations.

A WebDAV MOVE operation is a namespace operation -- it is moving the name
by which a resource is identified, not necessarily the representations
associated with that resource.  The degree to which operations on the
http namespace correspond to physical moves on the server backend is
tied to the degree that the resource being moved is tied to the server
backend.  However, the client knows nothing about this; it is something
that the user can know from out-of-band information, but it is hidden
from the client to prevent breaking the independence of client and server
implementation.

All references are referring to a specific resource.  The question is
whether that resource is exactly equivalent to the semantic mapping
intended by the reference, or whether it is only incidental to that
mapping.  There are numerous ways in which a reference can become
broken, most of which I outlined in the MOMspider paper at WWW1, but
the most common problem is using a reference that identifies the
wrong resource because it is simpler to refer to an implementation
mapping like a filename than it is to generate a more permanent mapping
specific to the resource semantics.

The ultimate problem then with maintaining referential integrity is that
it is very difficult for the server to know whether the user is changing
the name of the existing resource because they just want a new name for
the same resource, or because what is currently being mapped by that
resource does not actually correspond to the semantic mapping desired by
the references.  The former case desires the references to move with the
resource, whereas the latter case requires that the references not be changed.

If we were able to stick with a theoretical perspective, then we could
say that MOVE always results in the references being moved as well,
leaving the second case to be partially solvable only by a COPY and then
PUT or DELETE.  I say partially because this still does not consider the
very frequent case of wanting to refer to a resource before any
representations of the resource exist, or between times when they do exist.
However, we already know that not all servers will implement referential
integrity on a MOVE, and further that referential integrity on one server
doesn't mean much when the references on other servers are controlled
by other authorities.  Likewise, physically moving one representation
will impact many resources, since some resources are defined by the
presence of a representation.

The result of all this muttering is that WebDAV cannot know whether a
reference to a resource is "strong" or "weak" unless someone who is
smart enough to know the social ramifications behind the particular
namespace in question can tell the controller of the reference whether
it is strong or weak and give the controller the opportunity to refuse,
which is essentially equivalent to making it a property of the reference
that is setable via an option when the reference is created.

....Roy

Received on Thursday, 8 October 1998 19:09:48 UTC