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

RE: Internal and External Members

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Wed, 28 Jan 1998 09:29:03 -0800
Message-ID: <01BD2BCF.2D1DE340.ejw@ics.uci.edu>
To: "'SKREDDY@us.oracle.com'" <SKREDDY@us.oracle.com>
Cc: "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
On Tuesday, January 27, 1998 6:15 PM, Surendra Reddy 
[SMTP:SKREDDY@us.oracle.com] wrote:
>    Yaron,
>
> 	I agree with you in creating a separate spec for external members and
> 	ordered collections.
>
> 	[ Yaron ]
> 	.. I realize that there is some hesitation in having a separate spec for
> 	.. ordered collections and external members but I would like to assure
> everyone
> 	.. that a separate spec in no way deprecates these features.
>
> 	[Surendra]
> 	I would recommed merging this spec into main spec once consensus is
> reached.
> 	I am little bit concerned about having too many specs.

The issue of how to package functionality into specifications is always a 
tricky one.  There is a tension between making one large specification and 
making several, smaller specifications. The potential benefit of a larger 
spec. is greater internal consistency of the design, and the possibility of 
having a more feature-rich protocol. Plus, a larger spec. allows the 
procedural overhead of getting a protocol approved to be spread over many 
functions, resulting in lower overhead per function.  The pitfalls of large 
specs. are many.  The longer a spec. becomes, the harder it becomes to get 
good quality comments and feedback.  This is a volunteer organization, 
hence time spent reading and commenting on a spec. is often borrowed from 
other projects.  Also, the longer the spec., the longer it takes to finish, 
with associated problems of maintaining interest and relevancy.  Large 
specs. have an emotional impact as well -- large specs. imply lots of 
complexity, and long times to implement, whether this reputation is 
deserved or not.

There's a common belief that if a feature makes it into a specification 
that becomes an RFC, this feature will automatically be widely implemented. 
This is not true. Yet this belief drives some of the desire to load 
functionality into a specification, to make a specification larger. 
 Whether a feature is in the Distributed Authoring spec., or in a separate 
spec., it will only be implemented if it makes sense to people to implement 
it.

In summary, I see more advantages than pitfalls to several specs.

- Jim
Received on Wednesday, 28 January 1998 12:53:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:44 GMT