- From: Jim Davis <jdavis@parc.xerox.com>
- Date: Wed, 19 Aug 1998 11:07:17 PDT
- To: WebDAV <w3c-dist-auth@w3.org>
In my opinion there is exactly one problem, which, while we can't solve completly and in the general case, we can still help with considerably. I think the problem is that at present, there is no interoperable means for navigating _up_ the containment graph for the case of multiple containment. Please let me explain. WebDAV section 4 defines collections as intended "to model collection-like objects (e.g., file system directories)". Here, containment forms a tree. Each Web resource is an internal member of exactly one collection. Given the URL of the resource, one may obtain the URL of the collection by mere syntactic operation on the URL. So upward navigation is easy with internal members. But certain Document Management Systems (e.g. DocuShare) have a richer notion of containment, where containment is a graph, not a tree. An object may be be contained in multiple collections, no one of which is its "true" parent. It was the desire to support this kind of containment that led us to propose referential resources. You place object X into collections A, B, and C by placing referential resources (R->X, S->X, T->X) into each collection. The problem is that given only (target) X, there is no way to get back either the set of all resources whose target is X {A/R, B/S, C/T} or the set of collections {A, B, C}. So navigation upwards is possible for some kinds of containment (internal members) and not for others. This is bad. The solution is obvious: backpointers from a referential resource's target. (Given a backpointer to the ref. resource itself, one can then find the collection in which it is an internal member). But as we know (from discussions of "strong" references, this is *very hard* in the _general_ case, so we left it out of ACR. However, while it may be hard in the general case, for a DMS, it is not hard, in fact it is easy. So any sensible DMS vendor will simple define a read only special property that holds the backpointer (either to the collections or to the references). At this point, the only remaining unhappiness is that since each vendor defines its own propietary property, there's no _interoperable_ means of getting back to the parent. The lack of interoperablity is bad (we should fix it if we can) but not horrible (there will likely be other forms of incompatibility among DMSs anyway). So I propose that ACR define a new _optional_ property as follows Name: references Namespace: DAV: Purpose: Holds a list of referential resources whose target is this resource. <!ELEMENT references (href*) > This property is optional. Defining and standardizing this property will allow interoperable navigation for those implementations able to support it, and will cost little. Since it is read-only, no issues of transactionality or side-effect arise. Any objections?
Received on Wednesday, 19 August 1998 14:10:29 UTC