- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: Fri, 18 Dec 1998 10:15:37 -0500
- To: "'WebDAV'" <w3c-dist-auth@w3.org>
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