- From: Judith Slein <slein@wrc.xerox.com>
- Date: Wed, 19 Mar 1997 14:49:53 PST
- To: w3c-dist-auth@w3.org
- Cc: russell@wrc.xerox.com, sauvain@wrc.xerox.com, mccue@wrc.xerox.com
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