- From: Jim Amsden <jamsden@us.ibm.com>
- Date: Tue, 6 Oct 1998 19:31:00 -0400
- To: <w3c-dist-auth@w3.org>
I have been asked to reiterate and clarify my objections to including backpointers in the WebDAV Advanced Collections specification. Although as I have said in previous messages, I have no particular objection to backpointers, I have a number of reasons for not including them in the WebDAV spec. My major objection is simply that there are a potentially infinite number of (live) properties that servers may choose to support. These could be based on server implementation, or associated with a particular application's use of a set of resources. It is impossible to predict what all these properties might be and what semantics they might have. We have to draw a line in the sand somewhere on what are DAV properties, and what are application or server specific properties. This is what the properties mechanism in WebDAV-08 was intended to support. Resources can have any properties they want, and servers can choose to support any live properties they want using a well-defined extensibility mechanism. Because property values are XML elements, a property can also be included that provides the DTD for these elements, perhaps as the property of some other related resource. Establishing "standards" for such properties consists of agreeing on these (perhaps implied) DTDs. That is what XML was designed for, and WebDAV properties makes good use of this important feature. Second, I think DAV properties should be minimized (and they are), and limited to the properties that are required to support the protocol. If no WebDAV method requires a backpointer in order to describe its semantics, then backpointers shouldn't be DAV properties. Finding links to a resource does not require a backpointer. It can be done, albeit inefficiently, by doing a search. The DAV spec should not be in the business of specifying implementations, even optional implementations. It should only specify behavior, semantics, and protocol mechanisms. Third, the ability to support backpointers is clearly server dependent. Some WebDAV servers will delegate to multiple backends, so the capability will also be resource dependent. (Note the same arguments apply to anything involving referential integrity of links). Therefore support for backpointers and referential integrity would at best be optional on a resource-by-resource basis. Although it is possible to specify a protocol that supports this, it will be difficult to write and USE clients that use it. WebDAV should minimize the number of optional features otherwise client complexity will outweigh the benefit. A protocol that has many options does not result in improved interoperability because of the number of permutations of options clients must be prepared to work with/around. I continue to encourage a conservative approach, and when in doubt, leave it out. This will facilitate building WebDAV servers on a large number of repository managers, simplify client applications, promote ease of use, and limit barriers to entry for WebDAV. Client applications are likely to be authoring browsers for some time to come. These applications are complicated enough without having to do a lot of work to configure themselves for many different servers providing a large number of optional features. WebDAV should concentrate on specifying fundamental, core capabilities, get them in client hands sooner than later, and let the customer tell us what more they need. Getting these core features in developers hands is likely much more important that most of the proposed options.
Received on Tuesday, 6 October 1998 19:27:27 UTC