- From: Marcus Jager <mjager@microsoft.com>
- Date: Wed, 7 Oct 1998 12:33:58 -0700
- To: "'WebDAV'" <w3c-dist-auth@w3.org>
How about looking at it this way... A reference can be referring to one of two things. A. It is referring to a location in the URL namespace (consequentially referring whatever resource is available there) B. It is referring to a specific resource (consequentially it should follow that resource as it moves) Type A corresponds to "weak" references. Type B is what we have been calling "strong". We can throw out the strong/weak/integrity characterization. I think this more closely matches what servers/clients actually want to use references for. Type A references cannot be "dangling" since they reference a specific location irrespective of the existence of a resource there. If a reference of Type B loses track of the resource it is referring to, then it can revert to a Type A reference to the last place it knew about the resource. Thus what "dangling" is also handled for Type B. Also creation of Type B references would be server optional, it should be possible to decide to make Type A references non-optional. Typically only Type A references will be possible across servers since we don't yet have a standard way of tracking resources independent of URL. How about the terms "location reference" and "resource reference". Note that these would be orthogonal to direct/indirect references. Marcus. > -----Original Message----- > From: Slein, Judith A [SMTP:JSlein@crt.xerox.com] > Sent: Wednesday, October 07, 1998 08:48 > To: 'WebDAV' > Subject: Client Option for Strong References > > Here is the promised summary of the conference call discussions related to > this issue. > > Issue: Should the client be able to request creation of a reference whose > referential integrity is not to be enforced? > > Scenarios offered in support of this requirement: > > The owner of a target resource needs to take it offline for a short period > of time, say a week. It would be useful for the references to that target > to stay in place. During the period when the target does not exist, the > server responds to GET requests with "404 Not Found", but when the target > is > restored, the references work again without having to be recreated. > > A collection administrator may decide to create references now, in > anticipation of targets being available in the near future. > > Arguments: > > It is unlikely that a server implementor would allow referential integrity > to be turned on or off. > > What are the semantics of dangling references like? Will they really > reconnect automatically if the target is recreated? We need to understand > the semantics of dangling references before we can see whether this > requirement makes sense. > > It was agreed that if we give the client a choice, it should be at > reference > creation time, not at target deletion time. > > General discussion about referential integrity: > > The best we can expect from any server for referential integrity is best > effort. Probably referential integrity will be implemented only for cases > where reference and target are on the same server or a family of > collaborating servers. Even then, it may not be possible (disks may not > be > mounted). Some servers may support multiple back ends, some of which will > preserve referential integrity, while others do not. The same server may > change over time, supporting referential integrity at some times but not > at > others. > > Apache will not implement referential integrity for direct references. > Implementing referential integrity must be optional. > > Servers may or may not perform consistency operations. Do clients need to > know whether they do or not? > > We decided at Redmond to include referential integrity in the > requirements, > but to defer everything related to referential integrity for the protocol. > > Judith A. Slein > Xerox Corporation > jslein@crt.xerox.com > (716)422-5169 > 800 Phillips Road 105/50C > Webster, NY 14580 >
Received on Wednesday, 7 October 1998 15:34:07 UTC