Backpointers

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