Lists Home |
Date Index |
> Quite simply, small development groups are more productive than large
I don't know that productivity is the most important criterion. When people
owe their livilihoods to a specification, it should be maintained in a public
and open process with some combination of ombudsman, special-interest
protectors and democacy, not by secret enclave. Maintanance of a standard
is not a papal election.
Take the case of XML 1.0. There was a large semi-public group (of over
100 people?) which nutted through most issues, then a smaller group (10 or so)
which figured out what the consensus/outcome/implementation of the larger
group's debate was, then a smaller group (the editors, two or three) who figure
out what the consensus/outcome/implementation/wording of the working
group was, then finally the W3C director (who was available to toss the
coin if people could not get consensus on an isue that needed to be decided,
and to confirm that procedure had been followed and that the thing seemed to
fit in with the rest of the Web.)
The largest group represented in turn the opinions and expertise of many more.
So XML is an example of outside-in standards development.
Lets look at XML 1.1 in contrast. There we have inaccessible discussions by a tiny
group on something that impacts a lot of people. There is no mechanism to
try to ascertain even basic questions such as "Is an XML 1.1 acceptable, or
should we go to XML 2.0".
XML Schemas is similar. There are certainly attempts to get feedback, and
having regular staged public drafts helps prevent the misconceptions that
would arise from peicemeal presentation of changes. But if all WG discussion
were made publicly readable (except on issues relating to disclosure of IPR)
how could the final spec be worse. To the contrary, people would understand it
more, real deficiencies in approach would have beed discovered earlier, and
there is more of a chance that the big questions (such as "what is a markup
language?" and "should XML be a format which can be used to serialize any
database data including null characters and null values?") would have to
be answered, resulting in more cohesive architectures rather than the
current situation where we have streams of individual artifacts based on
decisions we don't know the basis or consistency of.