W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1998

Barrier to entry must be low

From: Babich, Alan <ABabich@filenet.com>
Date: Tue, 30 Jun 1998 15:05:44 -0700
Message-ID: <72B1992276A9D111A20E00805FEAC96DCC411B@cm-expo1.filenet.com>
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.


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 

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:13 UTC