Subject: Optional Backpointers from Targets to References

From: Jim Amsden <[email-masked]>
Date: Tue, 15 Sep 1998 17:39:53 -0400

This property may be impossible to support for a number of reasons. First its
the same problem that makes maintaining referential integrity difficult and
that has been deferred. Second, there may be significan performance
consequences of trying to maintain the references. And third, creating a
reference to a resource will require modification of the target resource to
update its properties while that resource may not be updatable by the
requesting principal. This is not a good reason for prohibiting a reference. I
recommend that we keep things simple and not add the requirement.

[email-masked] on 09/15/98 04:02:41 PM
Please respond to [email-masked]
To: [email-masked]
cc:
Subject: Optional Backpointers from Targets to References

There has been no discussion following Jim Davis's mailnote "Proposal:
optional backpointers for ACR" of August 19.  Unless there are
objections, this proposal will be incorporated in the Advanced
Collections protocol specification, and a corresponding requirement will
be added to the Advanced Collections requirements.

The requirement will state:

There is an interoperable means of navigating from a resource that is
the target of multiple references up the collection hierarchies from
which it is referenced.

The protocol specification will include:

The definition of a new, optional property DAV:references, which
provides backpointers from a target to all resources that refer to it.

This property is live on servers that choose to support it.  It may be
present on resources on other servers, but in that case will be dead.

Clients can use this property to discover which resources reference the
target resource, and by parsing the URLs of the references, can discover
the collections where those references reside and navigate up the
collection hierarchy.

Judith A. Slein
Xerox Corporation
[email-masked]
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

---

From: Greg Stein <[email-masked]>
Date: Tue, 15 Sep 1998 14:39:53 -0700

However:

1) the property is optional. If it is tough for a particular
implementation, then they can choose to not implement it

2) if the perf is too much, then a server can avoid it

3) if the property is implicit, then an real update may not be required.

Given that some implementions can handle back-references without much
problem, then it would be quite nice to be able to extract them.
Especially if the server keeps telling you that you can't delete it
because of other references. Without this, it would be quite a bear to
find those other refs.

-g

--
Greg Stein ([email-masked])

---

From: John Stracke <[email-masked]>
Date: Tue, 15 Sep 1998 14:58:10 -0700

Jim Amsden wrote:

> And third, creating a
> update its properties

I don't believe that has to be a problem.  The ACLs can be set up so that they
specifically permit the backpointer property to be updated by the server.  (Come
to that, it's a live property, so write access may not mean very much in the
first place.)

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      |"But she calls her ship _Mercy of the    |
[email-masked]      | Goddess_!" "Kali." "Oh."                |
\====================================================================/
New area code for work number: 650

---

From: Jim Davis <[email-masked]>
Date: Tue, 22 Sep 1998 11:43:18 PDT

Jim Amsden and other have asked me to explain the usefulness of the
backpointer.

Before I do, I want to emphasize that I am well aware that there are many
reasons why a server couldn't or shouldn't provide backpointers from *all*
targets  to *all* references.  I hope here only to show that there are
*some* applications for which this is useful, and then to argue that it's
worthwhile standardizing the protocol so that  applications that *do* use
this feature will have a standard way to access it on those servers that
happen to provide it.

Reasons it is useful:

1) Referential integrity.  Some applications desire references that are
guarenteed to remain valid, even when the target moves.  The easiest way to
do accomplish this is by storing back pointers from the target to the
reference.
While there is no requirement that the backpointer be exposed in the
interface, there is no harm in doing so.

2) Multiple containment.  Some document management systems have an abstract
notion of a 'document' that can be in many 'folders'.  For any such
document, it is sometimes necessary to obtain the set of folders in which
it appears.  The most direct mapping of these abstractions to WebDAV
(assuming Advanced Collection Resources) is:
 folder ::  WebDAV collection
 document ::  WebDAV resource
 containment :: WebDAV reference

That is, if document D is in folder F, there is a reference resource in F
whose target is D. Then, to find the set of all folders {F, G, H...} that
contain
document D, one first obtains the set of backpointers on D, then
(trivially) obtains the set of collections that contain those references.

3) Generality/Extensibility:  Backpointers are used in countless data
structures (consult any textbook on data structured or algorithms).  There
will certainly be uses we can't anticipate now.  The 'multiple containment'
example above is just the first one.

I hope to have demonstrated the usefulness of the dav:references property.
It will be optional, and hence cost-free, but useful to those applications
and servers who need it.