- From: Babich, Alan <ABabich@filenet.com>
- Date: Tue, 30 Jun 1998 15:05:44 -0700
- To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>, "'www-webdav-dasl@w3.org'" <www-webdav-dasl@w3.org>
As Youron said in the last Redmond meeting, "In a perfect world, a standard would codify what everyone is already doing." No one disagreed with him at that meeting. We all know that the world is imperfect. However, it is still useful to remember the ideal in order to guide our tradeoffs. Points 1 and 2 below are direct consequences. Point 1: One thing we must try to avoid is codifying nonexistent practice. That is, designing functionality that no one is currently providing, thereby designing future systems for the industry as a side effect. Such designs are unlikely to be optimal, since they do not have the benefit of real world experience. Point 2: Another thing we must try to avoid is to require functionality that is provided by only a fraction of the existing systems instead of specifying such functionality as optional. That requires all conforming systems to implement new functionality just to be conformant. Thus, that raises the barrier of entry. The higher the barrier of entry, the fewer systems will bother to conform, and the lower the probability of acceptance of the standard. We want to be as inclusive of existing systems as is reasonable. It is clear that an layer of software that sits on top of existing systems must be written to convert between WebDAV HTTP operations and the API's of existing systems. That is unavoidable. However, the ideal is that this is the only new software that will have to be written (or modified) to conform. In other words, we should try to avoid requiring enhancements to the document management engines and query engines of existing systems. Tradeoff: There is a fundamental tension between interoperability and inclusivity. On the one hand, we would like all features to be mandatory, because that maximizes what you the client can depend on, simplifies generic clients, and tends to maximize interoperability. On the other hand, requiring features not already provided by existing systems raises the barrier of entry, and minimizes inclusivity. Therefore, we have to be extremely thoughtful about what we make required. We have to accept the fact that not everything can be required. For example, WebDAV has already accepted that fact by making locking optional. Basic Principle: The basic principle is that the barrier of entry must be low. I'll be referring back to this e-mail in future e-mails. Alan Babich
Received on Tuesday, 30 June 1998 18:08:21 UTC