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 14:10:29 UTC