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. chas