[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Revising the OASIS TC process
This message is to bring members of the OASIS Process Advisory
Committee up to date on some recent developments with regard to
the OASIS TC process and to begin a discussion of how to move
forward from here.
On February 25, 2001, I submitted a request for the creation of an
OASIS TC to develop a set of standard grammars for XML business
documents to Karl Best, Director of Technical Operations for OASIS
and a member of this committee (which continues to function as we
decided at our last meeting in Paris). Under the process
developed by this committee and adopted by the OASIS board of
directors last year (Article 14(c) of the OASIS Bylaws dated
October 13, 2000), OASIS administration was supposed to proceed as
follows:
No later than 15 days following the submission, OASIS TC
administration shall either provide these materials to the
membership, with a call for participation and an announcement
of a first meeting, or return the submission to its originators
with an explanation of its failure to meet the requirements set
forth in this section. If the submission is accepted, OASIS TC
administration shall form two electronic mail lists for the TC,
namely a general list and a comment list, as described further
in the section titled "TC visibility," and the person named as
chair of the TC shall be given administrative control of these
lists.
Members of the PAC will recall that we designed the process in
such a way that approval of the OASIS board was not necessary for
the creation of an OASIS TC. The board was left out of the
process in order to speed up the creation of TCs and to remove
from the board the burden of attempting to manage technical
coordination among various possibly competing industry
standardization efforts. We knew from experience in other
standards efforts that attempts to coordinate technical work in
this space are ultimately futile and impose an immense resource
burden upon bodies that attempt to perform such coordination, and
we knew that the board, by its nature, would become a bottleneck
that would slow down the creation of TCs to an unacceptable
degree. Therefore, we structured the process in a way that left
the ultimate decision about the approval of standards to the
voting members of OASIS in a second phase of standardization
rather than requiring the board, or someone designated by the
board, to attempt the a priori coordination of technical standards
in a field that is still evolving.
Instead of proceeding under this process, however, OASIS
administration took my request to the OASIS board. The board, for
reasons that are still unclear to me, decided to put a moratorium
on the creation of technical committees related to ebXML, and it
applied this moratorium to the TC that I was proposing even though
it was not a continuation of any ebXML work item but was rather an
attempt to standardize CBL, a separate specification that predates
the ebXML initiative by a couple of years.
As members of the PAC will understand, the board's rejection of a
completely legal request for TC formation was in direct violation
of the OASIS bylaws as amended last year. The board, renaming
itself "the Board of Directors of SGML Open, d/b/a OASIS" for the
occasion, first attempted to rationalize this by simply denying
that the bylaws had ever been amended:
http://www.oasis-open.org/members/bod_minutes_03_01_01.shtml
Apparently persuaded of the absurdity of this position by legal
counsel, the board, now calling itself "the Board of Directors of
OASIS, Inc.," then reversed itself and solved the conflict by
rescinding that part of the bylaws that instituted the TC process:
http://www.oasis-open.org/members/bod_minutes_03_12_01.shtml
The actual resolution passed by the board reads as follows:
RESOLVED: That the By-laws are hereby amended by deleting
Articles 14 and 15 in their entirety, that the Board hereby
adopts as OASIS's Technical Committee Policy the document
attached as Attachment A to these minutes, and that the
By-laws, as amended, shall be as set forth in Attachment B to
these minutes.
So the TC process is no longer part of the OASIS bylaws but is
instead an OASIS policy. This does not diminish the violence that
has been done to that policy by the board's action in denying a
properly formed TC proposal, but it does clearly affirm the
board's ultimate authority for the actions of OASIS as a
corporation.
As the committee that engaged in the seven-month effort to define
the OASIS TC process, I feel that we in the PAC bear some
responsibility for the recent breakdown of that process, and as
the chair of the PAC, I feel personally responsible for what has
happened.
In my opinion, we made a basic mistake. We used our collective
experience in standards work to create a process that would
shelter the board from a task we knew was beyond the ability of
any group of elected volunteers, namely the coordination of
technical specifications in an area whose evolving complexities
surpass human understanding, but we based that process on a
principle that these people apparently cannot live with, which is
that the best solution will be determined by experience and not by
top-down design.
I'm no lawyer, but I believe it to be a basic fact of corporate
law that the OASIS board is legally responsible for the actions of
OASIS as a corporation and is therefore legally justified in
exercising its authority to prevent the creation of a TC it
doesn't like. We know that the board is buying itself a world of
pain by putting itself in the position of gatekeeper, but it's
clear that the majority of the board would rather put itself in
that position than allow the tough decisions to be made by the
OASIS membership in the light of actual experience.
Tommie Usdin's recent comments on this list are of particular
relevance here. Speaking of "the basic principle behind the
entire process," she said:
| We agreed on the value in letting people work on anything,
| including:
|
| - allowing several contradictory or conflicting activities,
| which were allowed but not obligated to coordinate;
|
| - activities that were unlikely to succeed; and
|
| - activities that were of interest to only a few people or
| organizations.
|
| We agreed that this was a good idea partly because control of
| the technical agendas of the TCs was impractical (as the number
| increases the control burden increases exponentially) and (more
| important) because it stifles innovation. We cited the W3C's
| control of XSL, and some were of the opinion that both XSL and
| CSS suffered from forced coordination and consolidation.
It appears, regrettably, that the board is determined to ignore
this experience. As stated in the minutes of the March 12
meeting,
Discussion followed regarding the degree of authority which the
Board should have over, and involvement in, the creation and
operation of Technical Committees, and it was agreed that the
Board should have overall authority over the Technical
Committees and their process, and that a general statement
should be included in the By-laws and/or the Technical
Committee rules at a later date.
In my opinion, the board is denying the OASIS membership the right
to make the important decisions by preventing those decisions from
ever coming to a vote of the members. But in light of the board's
ultimate authority over the affairs of the corporation, it seems
to me that this is a political issue rather than a process issue.
Since it will always be possible for the board to intervene in the
TC process, I think we should rethink and redesign parts of the
process so that the board can intervene in an orderly and legal
way, without risking public embarrassment, while still preserving
as much of the process as possible.
In recent mail to the Chairs list, Karl said:
| The OASIS Technical Advisory Committee (TAC, a committee of the
| OASIS Board of Directors) would like to get some feedback from the
| TC chairs regarding some possible changes to the way we manage our
| TCs.
Advising the board on process is clearly the job of this Process
Advisory Committee, not the Technical Advisory Committee.
| The OASIS TC Process is built around the philosophy of openness:
| any OASIS member can propose and form a TC on any topic, any OASIS
| member is allowed to participate, all TC proceedings are visible
| to the public, etc. This philosophy is extremely important to
| OASIS and we do not want to do anything that would change this.
Indeed, the fact that "any OASIS member can propose and form a TC
on any topic" is widely considered to be a unique and valuable
feature of the OASIS process. Unfortunately, it is just this
feature that is at risk.
| On the other hand, we have little oversight of what technical work
| OASIS does. With just about every new TC that we form we get
| questions from the public asking why OASIS is pursuing the new
| work. It appears that OASIS has no technical agenda.
We could say that public misperception of the process is best
dealt with by educating the public regarding the goals and design
of the process, but that would be missing the point here. I think
the heart of the problem is that we wish to allow members to
create TCs on subjects of their choosing and *also* for OASIS to
form a technical agenda and create TCs to pursue that agenda. (I
am setting aside the question of whether it's wise for OASIS to be
setting technical agendas and going with the observation that the
board will want to do so regardless.)
| The TAC is concerned about this situation, and has been discussing
| ways in which to provide some sort of oversight over our technical
| work while not doing anything to restrict the openness of our
| process. The TAC has suggested the following plan, and would like
| to hear your comments before proceeding any further.
|
| 1. A Technical Architecture Board (TAB) would be organized
| consisting of representatives of the TAC, OASIS staff, TC chairs,
| invited experts, etc.
We know from experience in other organizations that assigning
chairs to coordination groups reduces the time they can devote to
chairing their committees in direct proportion to the usefulness
they can contribute to the coordination group. I don't have a
solution for this, but it will have to be considered.
| 2. The TAB would define a set of "portfolios" or topic areas for
| technical work. For example, there could be a portfolio for
| e-business, another for conformance work, etc. Existing and new
| TCs would each be assigned to a portfolio by the TAB. The TAB
| would allocate available resources to the portfolios to encourage
| work that OASIS feels is important.
"Available resources" presumably means funding from OASIS dues.
Note the implication that existing and future member-initiated TCs
might find themselves managed in a way that they never anticipated
or would have agreed to when first proposed.
| 3. Each portfolio would include coordination, management, a common
| architecture as necessary, etc. to ensure that the TCs are working
| collaboratively.
There's a lot of hand-waving here. You can't implement
"coordination, management, a common architecture as necessary,
etc." without a ton of procedural specification. It took several
agonizing years for W3C to learn this.
Beyond the details, this proposal seems to me a bad idea for two
reasons.
First, this is similar to the model that we have seen operate more
and more slowly while sucking up more and more resources in the
W3C. If it doesn't scale in an organization with much greater
resources than OASIS has, it won't scale here. But it seems clear
that the board is determined to learn this the hard way.
Second, the creation of a Technical Architecture Board will put
OASIS in direct competition with W3C. Those of us who urged OASIS
to go in its current direction a couple of years ago wanted to see
it develop into an organization that would complement the work of
W3C by allowing industry groups to design their own XML languages
while W3C concentrated on generic web technologies. The fact that
there is some overlap between the two organizations in initiatives
proposed by OASIS members should not encourage OASIS itself to
sponsor initiatives that will be perceived as direct competition.
| We haven't yet worked out all the details of this plan, but like
| the idea so far. I have looked at the official OASIS TC Process
| and find little that would need to be changed to accomodate this
| plan. This plan would seem to provide some oversight over our
| technical work without restricting the openness of our process.
I don't think this is true. The structure that Karl suggests is
not provided for either by the TC process or, in my opinion, by
the OASIS Bylaws, which specify committees in a way that limits
them to an advisory role. (This limitation is why we started the
PAC in the first place, but apparently the lawyers have a
different interpretation.)
| We would like to get your comments over the next few days; the
| board will be meeting next week on Wednesday and Thursday and
| would like to discuss this idea further. Feel free to discuss on
| this list, or send your comment privately to me. Please focus on
| the philosophy rather than the details of the suggestion.
OK, here's my input.
On the one hand, we want to preserve the ability of individual
members to create technical committees to define XML
specifications and then, if they wish, to propose their work to
the OASIS membership for standardization. On the other hand, the
board and some members of the OASIS staff want to be able to
create "official" initiatives and to allocate OASIS resources to
those initiatives.
So I propose the following as starting points. Undoubtedly some
further thought will be required.
1. Keep the TC process as currently defined, with two
modifications:
a. Call the TCs created under this process "OASIS Member
TCs" to indicate that they are not funded initiatives of
the OASIS board.
b. Insert language that will allow OASIS administration to
bring a proposed Member TC before the board for review
within the 15 days allowed for by the current process.
2. Add new language covering the creation of "OASIS Portfolios"
(or something like that) so that the board can sponsor and
fund technical initiatives of its own choosing. TCs created
under this part of the process should be called something
like "OASIS Portfolio TCs" to indicate that they are
sponsored by and receive funding from the board. This new
language will specify "coordination, management, a common
architecture as necessary, etc." It should avoid the
creation of anything that looks like it's trying to compete
with W3C.
The new process for OASIS Portfolios will be difficult to design
and implement, and I predict that initiatives created under this
new part of the process will prove to be an unmitigated headache
for the board and a bottomless resource sink, but at least it will
give form to an urge that appears to be unstoppable. The task
before us is to help the Board avoid hasty decisions that will
come back to haunt this organization for years to come, and to
help introduce a certain measure of deliberation and
thoughtfulness into a process that, as the events of the past two
months show, can appear to be out of control.
Jon
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC