[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xdg
Subject:    Re: Bringing fdo.org to the next level
From:       CHonton () xteric ! com
Date:       2005-04-15 13:34:31
Message-ID: OFE785DB1D.8AF4601F-ON85256FE4.0047E34A-85256FE4.004AEF2C () xteric ! com
[Download RAW message or body]

This is a multipart message in MIME format.
--=_alternative 004AEF2685256FE4_=
Content-Type: text/plain; charset="US-ASCII"

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
--=_alternative 004AEF2685256FE4_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Standards work is a lot like legislation
(or sausage making). &nbsp;It is not for the faint of heart. &nbsp;I see
two major ways that standards (and legislation) are adopted: de-facto and
prescriptive. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">De-facto standards acknowledge what
already exists and is accepted. &nbsp;Documenting the existing practices
set expectations and allows others to use a the current body of work as
a foundation for future work. &nbsp;De-facto standards often help iron
out implementation differences in the corner cases, or allow very close
implementations to shift towards a compromise. &nbsp;Good examples of De-facto
standards include Unix.</font>
<br>
<br><font size=2 face="sans-serif">Prescriptive standards are more like
blueprints for the future. &nbsp;These standards try to mandate the production
of software. &nbsp; Depending upon the expertise of the standard writers,
prescriptive standards can be exactly what is required/desired. &nbsp;My
experience is that most prescriptive standards don't balance all the elements
&nbsp;-- usually it's too many features. &nbsp;A sterling example of prescriptive
standards is CORBA.</font>
<br>
<br><font size=2 face="sans-serif">I believe fdo has a proper balance with
the emphasis on de-facto standards. &nbsp;fdo standards are just that:
a standard way to do this or that. &nbsp;Not necessarily the correct or
best way. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">The recent discussions of standardizing
vfs and configuration have been very productive. &nbsp;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. &nbsp;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.</font>
<br>
<br><font size=2 face="sans-serif">chas</font>
--=_alternative 004AEF2685256FE4_=--

[prev in list] [next in list] [prev in thread] [next in thread]