Optional Backpointers (for the last time)

In Orlando we discussed optional backpointers again.  My impression was that
very few people really care about this issue, and those who do care were
unable to reach consensus.  Consequently, I am proposing to remove
backpointers from the specification unless I hear strong and numerous voices
of protest.

Here is a summary of the arguments we've heard so far:

Pro:

Navigating Up: Allows clients to discover which collections contain a given
target by reference - information for the end user of a DMS or configuration
management system

	Where might I find related documents?
	How is this resource being used?
	What configurations does this resource belong to? 

On a server that doesn't maintain referential integrity, clients can be good
citizens by checking for references before deleting.

On a server that blocks deletes where there are references, the client can
discover the references so as to delete them before attempting to delete the
target.

Follow the backpointers to replicate properties of the target at the
reference. 

	Discussion: There is no reason for the backpointers to be exposed to
clients.  It's the server that uses them in this case.

We need to define the property in order to get interoperability for
backpointers.  We need someone who buys a server that implements
backpointers to be able to use any (or many) clients to interact with it.
We need clients to be able to count on a certain implementation.

	Discussion: This is server value-add and should be standardized (if
at all) by a vendor community, not by WebDAV.

Any server that maintains referential integrity is keeping a property like
this anyhow, so it may as well expose the property to information to
clients.

Backpointers are so common in data structures that there are likely to be
unanticipated uses for this feature.

Con:

Raises at least some of the issues that led us to defer strong references.
(Need interactions between servers, security concerns - revealing to targets
the location of references, use up resources by creating lots of references
to a target.)

	Discussion: It won't be implemented for the general case (which was
the hard one for strong references), but only for local references.  The
general case would require interactions between servers, security concerns

Performance, efficiency (on the wire vs. on the server? Search vs. maintain
and retrieve property?), and scalability issues.  The list of backpointers
is unbounded.

	Discussion: We don't expect the general case to be implemented.  The
list would only include local references.

Security concerns: A hostile client could cause large lists of backpointers
to be created by creating lots of references.

Creator of the reference would have to have permission to update the
target's properties; otherwise the request to create the reference would
fail.

	Discussion: No, DAV:references is a live property that the server
updates when someone creates a reference or deletes a reference.

A search (on DAV:reftarget) would work just as well.

	Discussion: DASL doesn't include structured queries yet.

	Discussion: Search would be expensive relative to examining a single
property unless it was implemented as examining a property on the target.

	Discussion: Search could be implemented as a property, or a property
could be implemented as a search.  So the question is what is more natural
to do in the protocol.

	Discussion: Search behaves better than an optional property for
down-level servers 

	Discussion: What about servers that implement referencing but not
search?

Servers that are built on file system capabilities may find backpointers
difficult to implement.

Clients may assume that it is more efficient to access a DAV:references
property than to perform a search on DAV:reftarget.  However, depending on
the server's implementation this may not be the case.  DAV:references may be
computed on the fly.  This could be especially bad if a client tries to do
PROPFIND with allprop, as there may be other computed properties as well.

There's too much optional stuff in WebDAV already.  This just adds to the
client's burden in having to figure out what the server supports and be able
to work whether or not the server supports what it's looking for.  (Not all
servers will be able to implement it, and those that can may not be able to
implement it on all resources.)  Keep the protocol simple for clients.

	Discussion: It still is important for interoperability, so that
whenever backpointers are provided, they are provided in a standard way.

	Discussion: Even for federated servers, it might be possible for the
primary server to keep the backpointers for the backend servers.

Too many special cases for how the server has to deal with this. For
example, what happens when we add versioning? What if the target of a
reference is the tip revision - server has to update the DAV:references
property whenever a new revision is added, on both the previous tip and the
new tip?  Keep the protocol simple for servers.

	Discussion: Can live properties on a revision (frozen) change? Yes.

We should minimize the number of DAV: properties we define.  It should be
only the ones that are needed in order for the protocol itself to function.
It should be only the ones that are needed in support of some DAV method.

	Discussion: There's an important requirement being satisfied here.
We choose to satisfy it by introducing a property rather than a method.  We
could define a NAVIGATE_UP or GET_REFERENCES method.


Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

Received on Friday, 18 December 1998 10:10:41 UTC