- From: Judith Slein <slein@wrc.xerox.com>
- Date: Fri, 24 Apr 1998 13:19:04 PDT
- To: w3c-dist-auth@w3.org
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. 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. 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? 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. Name: Judith A. Slein E-Mail: slein@wrc.xerox.com Phone: (716) 422-5169 Fax: (716) 422-2938 Xerox Corporation Mail Stop 105-50C 800 Phillips Road Webster, NY 14580
Received on Friday, 24 April 1998 18:21:41 UTC