RE: Proposal: optional backpointers for ACR (Was: RE: Hierarchica l URLs and Collections)

Ick... How about just enhancing ADDREF to accept settings for parents and
mandating that parent settings have to be returned in PROPFIND? I believe we
should shy away from programmatic properties, even if they are read-only. 

			Yaron

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Wednesday, August 19, 1998 11:07 AM
> To: WebDAV
> Subject: Proposal: optional backpointers for ACR (Was: RE: 
> Hierarchical
> URLs and Collections)
> 
> 
> 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 20:42:46 UTC