W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1998

Collections and Referential Integrity

From: Judith Slein <slein@wrc.xerox.com>
Date: Fri, 24 Apr 1998 13:19:04 PDT
Message-Id: <3.0.3.32.19980424161904.00a54d40@pop-server.wrc.xerox.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:47 GMT