Bringing to the next level

CHonton at CHonton at
Fri Apr 15 16:34:31 EEST 2005

Standards work is a lot like legislation (or sausage making).  It is not 
for the faint of heart.  I see two major ways that standards (and 
legislation) are adopted: de-facto and prescriptive. 

De-facto standards acknowledge what already exists and is accepted. 
Documenting the existing practices set expectations and allows others to 
use a the current body of work as a foundation for future work.  De-facto 
standards often help iron out implementation differences in the corner 
cases, or allow very close implementations to shift towards a compromise. 
Good examples of De-facto standards include Unix.

Prescriptive standards are more like blueprints for the future.  These 
standards try to mandate the production of software.   Depending upon the 
expertise of the standard writers, prescriptive standards can be exactly 
what is required/desired.  My experience is that most prescriptive 
standards don't balance all the elements  -- usually it's too many 
features.  A sterling example of prescriptive standards is CORBA.

I believe fdo has a proper balance with the emphasis on de-facto 
standards.  fdo standards are just that: a standard way to do this or 
that.  Not necessarily the correct or best way. 

The recent discussions of standardizing vfs and configuration have been 
very productive.  Some teams may (or may not) take these discussions into 
the bit factory and produce components which may eventually seek 
standardization -- i.e. adoption by one or more desktop environments.  Our 
discussions on this list given hints to the implementation teams what 
features need to exist and what features need to be avoided in order for 
their components to be standardized.

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the xdg mailing list