- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Thu, 27 Mar 1997 17:24:00 -0800
- To: Judith Slein <slein@wrc.xerox.com>, w3c-dist-auth@w3.org
- Cc: russell@wrc.xerox.com, sauvain@wrc.xerox.com, mccue@wrc.xerox.com
At 2:49 PM 3/19/97, Judith Slein wrote: >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. Judith, I agree with you that referential integrity is an extremely important issue for handling metadata, and that the metadata model described in draft-jensen-dist-auth-00 does have serious referential integrity problems. This has led to the current set of proposals, which is a mixed model -- some metadata (small chunk) can be stored directly on the resource (using the META* methods, or whatever their final name may be), and then is moved, copied, and deleted when the resource is moved, copied, deleted (assuming the metadata is not specific to a particular location in the name space). Other metadata (large chunk) can also be accomodated, but it is now linked to. With this mixed model, the referential integrity problems are alleviated for the small chunk metadata, but still exist unabated for the large chunk metadata. I believe there is currently not much that can be done to alleviate the large chunk metadata referential integrity problems, due to the fact that resources outside the scope of control of the server managing a particular instance of a large-chunk metadata resource may refer to the metadata. In the worst (and for the near term, likely) case that these two servers (the one managing the large-chunk metadata, the other managing the resource containing the reference to the large-chunk metadata) are not cooperating, there is really very little that can be done. If both the referring and referred-to (metadata) resource are under the control of the same server, then a server could perform some intelligent operations to maintain referential integrity. >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.) This defniitely raises the issue of what we should require in terms of support for referential integrity. Perhaps we need to define a metadata attribute type (called DAV.Links.incoming) which lists all of the URLs of resources which have links that point to this resource. Supporting this link type can be optional. This would give a client the information it needs to maintain referential integrity. As for automatic server support of referential integrity of linked metadata, on this topic I'm ambivalent. Automatic support would be really nice, but I'm a bit uncomfortable with the idea that modifying one resource would automatically cause changes to the links of many other resources, since it makes the scope of effect of a method unknown. On the other hand, a user would undoubtedly want their links to be as consistent as possible with as little work on their part as possible. - Jim
Received on Thursday, 27 March 1997 20:24:37 UTC