Open standards processes

[Frank Boumphrey]

>>But I don't think it serves any purpose to be secretive. I
have certainly always believed that the more people knew
what was going on, the greater the chance of success.
Publishing work in progress will enable the user and vendor
community to respond more rapidly when the thing is finally
published, and will harness the resources of a wider group
of people to spot the errors. I find it a little
disappointing, now that there is no cost argument to prevent
open dissemination,<<

    I think thats very well said. Even if there were a deluge of feed back,
the compilers of the standard would be free to ignore it.

    I can think of no legitimate reason for secrecy.

    Even if the member-developers did want an edge on non-member developers,
(assuming that that's a legimitate reason, which is debateable) if they need
that kind of edge they have real problems and are not going to last very
long!!

Frank

-----Original Message-----
From: Michael Kay <M.H.Kay at eng.icl.co.uk>
To: xml-dev <xml-dev at ic.ac.uk>
Date: Friday, May 01, 1998 8:21 AM
Subject: Re: Open standards processes


>>Here are some more thoughts about open standards processes:
>>
>To add my tuppenceworth, I've been involved in the past in
>both de jure and consortium standards-making processes,
>though all before the days of the web.
>
>To get a successful standard you need a core team who work
>hard, who are technically highly competent, and who
>understand the needs of the users as well as (a more common
>reason for failure) the needs of potential vendors. You need
>a consensus on the general principles and objectives, an
>aversion to introducing unproven innovations, and an absence
>of people with an interest in obstructing the process. You
>don't need consultation or democracy or legal authority;
>these can sometimes help to achieve the necessary consensus
>but can also slow things down or send things off in the
>wrong direction.
>
>But I don't think it serves any purpose to be secretive. I
>have certainly always believed that the more people knew
>what was going on, the greater the chance of success.
>Publishing work in progress will enable the user and vendor
>community to respond more rapidly when the thing is finally
>published, and will harness the resources of a wider group
>of people to spot the errors. I find it a little
>disappointing, now that there is no cost argument to prevent
>open dissemination, that W3C should (apparently) have a
>policy of secrecy which goes beyond anything I ever
>encountered in ISO or ANSI or X/Open or OMG committees.
>Perhaps the problem is that they would be deluged by
>feedback, but I doubt it.
>
>Michael Kay
>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo at ic.ac.uk the following
message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>
>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)