W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1997

Re: Links and Referential Integrity

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Thu, 27 Mar 1997 17:24:00 -0800
Message-Id: <af60c7ba070210045b85@[]>
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.


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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:10 UTC