Links and Referential Integrity

We've been having some internal discussions at Xerox about WebDAV's
referential integrity problems.  Links are central to just about everything
we are doing.  Useful as they are, they expose us to problems about
referential integrity everywhere that cannot be ignored.  Where document
management systems sit behind the WebDAV server, we can probably rely on
them to enforce referential integrity.  But where the WebDAV server is
storing things directly in the file system, it must take responsibility for
maintaining referential integrity.  We can't ask the client to manage it.

Here are some examples, just to point out how pervasive this is for us:

(Examples 1 and 2 suppose the Irvine model of metadata, where an attribute
value is a separate resource linked to the resource it describes.)

1. I have two resources A and B that each have some attributes of their own
(author, title, etc.) and that share some other attributes (usage rights,
ratings, etc.).  I request that A be moved.  If the server allows this to
happen, it should make some decisions about whether to move the attributes
(links and values) that A owns, or whether just to fix up the links, and the
same for the shared attributes.

2. I delete resource R which, as it happens, is an attribute of resource A.
The link from A to R should be deleted.  (I don't think this is even
possible as WebDAV is specified because (1) the link type will not be
"attribute" but "publisher" or something not recognizable as an attribute
and (2) the link is attached to A, not R, so that you can't tell by
examining R that it is an attribute of anything.)

3. I have a resource A with English and French renditions.  Suppose that the
renditions get implemented as separate resources with links of type
"rendition" on A that point to them.  I delete the French rendition.  The
server should delete the relationship (A, A.fr, rendition).  (As in example
2, without a link on the rendition pointing to the parent resource, the
server cannot find the parent to delete its link.)

4. I have collections A and B.  Collection A contains resource C (relative
URL).  Collection B references resource C (absolute URL).  I request that C
be removed from collection A.  According to the spec, this will result in C
being deleted.  It's debatable how referential integrity should be
maintained.  Maybe the server should refuse to allow C to be removed.  Maybe
the server should get rid of B's reference to C.  In any case, something
needs to be done. 

5. I believe that we are already committed to having the server guarantee
the integrity of all links related to versioning.  When I check in a new
version, any required links between it and the previous version, version
history, version graph handle, default version are created.

6.  Now for the really interesting cases:  I have a version graph some of
whose nodes have multiple renditions.  So version 3 has a french rendition
and an English rendition.  I check out version 3 -- what do I get?  Have I
checked out both renditions?  If I update only the french rendition, do I
end up with version 4 that has only one rendition?  Or does the english
rendition go into version 4 also, even though it no longer says the same
thing as the french rendition?  If there are attributes on one version, are
they assumed to be carried forward to the next version (unless I change
them)?  Etc.  Servers need to have policies about these interactions between
different kinds of links.

WebDAV should not dictate any particular policy for dealing with specific
referential integrity problems, but I think we should require servers to
maintain integrity somehow, and we should make sure that it's possible for
them to do so.  (For example, an attribute that is implemented as a linked
resource should know which resources it is an attribute of.)

--Judy
Name:			Judith A. Slein
E-Mail:			slein@wrc.xerox.com
Internal Phone:  	8*222-5169
External Phone:		(716) 422-5169
Fax:			(716) 265-7133
MailStop:		128-29E

Received on Wednesday, 19 March 1997 17:52:08 UTC