RE: Collections and Referential Integrity

Comments below.

> -----Original Message-----
> From: Judith Slein [mailto:slein@wrc.xerox.com]
> Sent: Friday, April 24, 1998 1:19 PM
> To: w3c-dist-auth@w3.org
> Subject: Collections and Referential Integrity
>
>
> Based on the minutes of the April 2 WebDAV meeting, it sounds as if there
> needs to be more discussion of the collections requirements related to
> referential integrity.
>
> It was agreed at that meeting that there should be a new requirement
>
> N.2 It is possible to request creation of a referential member that
> the server will guarentee to have referentially integrity.
>
> Presumably if the client requests a guarantee of referential
> integrity that the server is unable to provide, the server must
> not create the referential member, but respond with some 4xx code.
> In cases where the target of the referential member is on a different
> server, it is unlikely that the server will be able to guarantee
> referential integrity.

I agree, and I believe this represented the sense of the room in LA.

> It looks to me as if N.2 is incompatible with the proposed "N.1 Operations
> on a target do not affect the reference(s)."  Guaranteeing referential
> integrity will sometimes require the server to modify the referential
> member.  For example, when the target is moved, the server must change the
> reference to point to its new location.

Good catch.  In this case, N.1 needs to be modified so the referential
integrity of "strong" links is always maintained, and the server should
refuse to create a "strong" link for which it cannot maintain its
referential integrity.  So the original wording of N.1 holds for "weak"
links, but not for "strong" links.

> Two other proposed requirements build on N.2:
>
> N.3 It is possible to discover whether or not a referential
> member has such 'integrity protection'.
>
> N.4 It is possible to discover whether a resource is the target of
> such a 'protected referential member'.
>
> N.3 would be easy to implement with a property on the referential member.
> But what is the rationale for this requirement?  Perhaps that for cases
> where constructing and submitting a request on the target resource is
> expensive, a client might want to check whether the target is
> guaranteed to be at the URI before attempting the request.  But if
> the answer is "No," it might still be there.  Wouldn't it be better
> just to do a HEAD on the target?

For me, the rationale was simply that the client should have a mechanism for
determining the expected future behavior of the referential member.  If
there is no way for the client to determine what kind of referential member
it is dealing with, it may have to adopt potentially wasteful strategies
(for example, if the client doesn't know the referential integrity is being
maintained, it might, as a matter of policy, re-create the referential
member to maintain referential integrity even if such integrity were
automatically maintained.)

> N.4 is probably equally easy.  If the server is in a position to guarantee
> referential integrity, it must be in a position to maintain a property on
> the target resource.  It is at least maintaining a reference count, and
> perhaps a list of referential members that refer to the resource,
> depending
> upon how it is maintaining referential integrity.  It is easier to see a
> rationale for this requirement -- I can imagine an author or owner of a
> resource wanting to know how many / which places are referencing it.

Another way of looking at these two requirements is that they ensure that
both ends of a referential integrity relationship have the same information
available.

- Jim

Received on Friday, 8 May 1998 16:53:58 UTC