[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: FW: Request for agenda item: Revisions to TC Policy
| We have requested that our Board Directors who are on the TAC (and
| any others who are interested) to attend the PAC call on Wed 8/22.
Great. Here's the telcon info:
dial-in number: 888 422 7101
participant code: 662 467
I'm copying the PAC on this as well. The call will begin at 11
a.m. and end at 1 p.m. California time 2001.08.22.
| Then we would like to have a PAC representative (expecting you,
| Jon, as Chair) to address the full Board meeting on 8/23, with the
| expectation that the full Board's discussion of the PAC
| recommendations/issues would be preceeded with the appropriate
| background info that Colin Evans (Board Chairman) and I can send
| to the Board members ahead of time.
OK.
| Jon, do you/PAC have any info on what you expect the Board to
| review/decide to submit now that I can include in the Board's
| pre-reading info package?
The board should review the public description of the process,
which has been out since last January on xml.com:
http://www.xml.com/pub/a/2001/01/17/oasisprocess.html
A copy is appended below.
Jon Bosak
Chair, Process Advisory Committee
==================================================================
<html>
<head></head>
<body>
<h1>A Scalable Process for Information Standards</h1>
<address>Jon Bosak, Chair, OASIS Process Advisory Committee</address>
<blockquote>
"As a practical matter, the ability of industry to develop
coherent semantic standards depends on the health of the
standards process."
<blockquote>
-- Scaffolding the New Web: Standards and Standards
Policy for the Digital Economy (RAND Science and
Technology Policy Institute, 2000)
</blockquote>
</blockquote>
<h2>The Need for an XML Standards Organization</h2>
<p>
It is becoming increasingly evident that the primary role of XML is
to provide a syntactic framework for the development of standard
semantics to enable the exchange of human-readable structured data
in corporate contexts. Developers of corporate
XML applications will often benefit
from the ability to confer upon certain XML specifications the
status of formal standards, or, in other words, to develop certain
specifications under the aegis of a formal standards development
organization (SDO).
</p>
<p>
An SDO for XML specifications should ideally have the following
qualities.
</p>
<ol>
<li>It should legally exist. In practice, this means that it
should be incorporated, preferably as a nonprofit
organization.</li>
<li>All intellectual property developed by the organization
should be made available to the public under a nondiscriminatory
license allowing free use.</li>
<li>Authority for governance of the organization should
be vested in its voting members.</li>
<li>The criteria for membership should be such as to encourage
the participation of all interested parties, with reasonable and
nondiscriminatory dues set at a level appropriate to the
maintenance of the organization.</li>
<li>The organization should be governed by a formal democratic
process.</li>
<li>The formal deliberations of the organization should be
archived and publicly visible.</li>
</ol>
<h2>OASIS as an Internet-speed SDO</h2>
<p>
OASIS, the Organization for the Advancement of Structured
Information Standards, is a nonprofit corporation founded in 1993
whose already open and formal process has recently been revised to
speed it up and implement some procedures electronically [1].
</p>
<p>
The designers of the new OASIS technical committee (TC) process
have attempted to capture the most effective features of
standards development groups ranging from traditional bodies
such as ISO and IEEE to web-oriented groups like IETF and W3C.
These features have been combined in a set of rules that
attempts to use technology to bridge the contradictory goals of
speed and formality. The intention has been to create a
process that operates at warp speed while retaining the audit
trail, IPR policies [2], and formal authority of a legally
chartered nonprofit organization.
</p>
<h2>High-speed Distributed Standards Development</h2>
<p>
Groups of experts forming technical committees (TCs) under the
OASIS process can create Committee Specifications very quickly --
in theory as quickly as 45 days from start to finish -- within a
framework that scales to accommodate an unlimited number of efforts
while maintaining legal accountability. A number of factors have
been combined to accomplish these goals: a reliance on
self-organization and the oversight of interested parties; an
innovative use of technology for formal standards development; and
a fallback to majority rule that drives the process forward even
when called upon to resolve major differences of opinion.
</p>
<h3><i>Self-Organization</i></h3>
<p>
OASIS TCs are self-organizing. Any group of three or more
OASIS members can form a TC to standardize virtually
anything related to the interoperability of structured
information systems. Corporation law makes the elected
OASIS Board of Directors ultimately responsible for all
decisions of OASIS, but the TC process makes its oversight
of technical committees largely administrative. Thus, the
TC process does not have to wait for approval from above to
get started. This enhances both speed and scalability.
</p>
<p>
The coordination of TCs is also self-organizing. The TC process
provides for both loosely structured, bottom-up coordination
between TCs and tightly structured, top-down coordination within
TCs. Each TC has the power to form cooperative relationships
with other TCs, building upward to form voluntary coordinative
structures to whatever extent seems needed or desirable. Each
TC also has the power to appoint traditional subcommittees,
recursively forming top-down control structures of any desired
complexity. </p>
<p>
Since all coordinative activities pertaining to a TC are
staffed by members of the TC, coordination is limited only
by the willingness of TCs to cooperate with each other.
This reliance upon the TCs themselves for the resources
needed to coordinate their activities drastically reduces
the enormous overhead typically required to coordinate
multiple standards committees.
</p>
<p>
The reliance upon self-coordination strongly differentiates the
OASIS TC process from other standards development methodologies
that operate under the control of a central authority (for
example, the W3C process and the Java Community Process). These
more centralized models of governance can achieve a much higher
level of coordination, but they cannot attain the open-ended
scalability needed for the definition of an unlimited number of
domain-specific XML vocabularies.
</p>
<h3><i>"Interested Parties": The Invisible Hand</i></h3>
<p>
A great deal of the scalability and relative simplicity of
the TC process derives from its reliance on interested
parties to contribute to and oversee the TCs in which they
have an interest.
</p>
<p>
Interested parties must provide all resources beyond mailing
lists, archives, and administration. Time and travel are the
responsibility of individual experts and their employers. The
costs of phone and face-to-face meetings are borne by sponsors,
typically companies employing some of the experts (the process
requires such outside support to be publicly declared). OASIS
member sections, which are structures separate from the TC
process, make possible the funding of efforts when an industry
group wishes to collectively foster the development of a
standard without making assumptions about its technical
direction.
</p>
<p>
Beyond providing many of the resources, interested parties
are also relied upon to watch over the work of the TCs, to
make sure that each TC is proceeding in the right direction,
and to safeguard against conflicts with the work of other
TCs. Keeping an eye on every aspect of XML evolution would
constitute a massive resource sink if it were attempted from
the top down. The TC process puts this burden on the
potential users of the technology under development.
</p>
<p>
To make it possible for interested parties inside and outside of
OASIS to act as watchdogs on a global basis, the TC process is
open and visible.
Every OASIS TC is open to participation
by any interested OASIS member, and every OASIS TC mailing list
is visible to the world at large, ensuring that its contents can
be freely discussed by anyone in any forum. The openness of the
OASIS TC process is designed not only to ensure public oversight
of the specifications under development, but also, in
conjunction with the low cost of OASIS membership, to allow
individuals and small organizations to participate in the
standards process.
This openness has the handy side effect of minimizing the
exposure of OASIS members to antitrust actions.
</p>
<h3><i>Using Technology to Streamline Standards Development</i></h3>
<p>
A key innovation of the OASIS TC process is the use of
electronic mail for certain types of formal business. The TC
process not only allows e-mail balloting of working drafts and
committee specifications, which is a simple extension of
traditional committee procedure; but it also permits TCs to
authorize their chairs to form and propose motions based on a
perceived consensus or best-fit solution. The ability to conduct
formal business by e-mail in TCs that agree to operate in this
manner can greatly increase the speed and reduce the expense of
building technical standards.
</p>
<p>
Another important cost-cutting feature of the TC process is that
phone meetings count as meetings. In theory, the total cost of
funding a TC that conducts most of its business by e-mail is the
cost of one phone conference per year.
</p>
<p>
Of course, most active TCs will wish to meet more often, and
some TCs will want to organize their meetings on the basis of
geographical location, but in the OASIS process, they don't have
to. As a result, formal business can be conducted very cheaply.
At the other extreme, TCs that really do wish to meet regularly
in expensive face-to-face meetings held all over the world, and
thus in effect to restrict their voting membership to people
able to attend such meetings, are also perfectly free to do so,
although the minutes of their work must continue to be publicly
available.
</p>
<p>
Different projects have different requirements for
face-to-face contact in international contexts, and the TC
process allows each TC to decide how it will handle its own
meeting schedule, whether local or global. Similarly, it is
entirely up to each TC to determine the language in which it
will conduct business and publish Committee Specifications.
</p>
<h3><i>Majority Rule</i></h3>
<p>
The OASIS TC process relies on consensus for most decisions.
But it also keeps on hand the full apparatus of
formal majority rule for the resolution of difficult
questions on those relatively infrequent occasions when
consensus cannot be achieved.
</p>
<p>
Formal majority rule has an undeserved reputation for
complexity. In practice, majority rule in a committee is very
simple; either everyone agrees on the right way to proceed --
which is the usual case -- or a vote is conducted and the
majority wins. But there's a trick to this. Using majority
rule to decide the tough cases works only when committees know
exactly who their voting members are. Detailed membership rules
built into the TC process ensure that this is always the case.
</p>
<p>
As a result, TCs can always move forward, without depending on
an external authority to make the hard decisions and without
worrying about whether an external authority is going to reverse
those decisions. Clear membership rules also enable another
essential procedural device, the quorum. Since a TC always
knows exactly who its members are, it always knows whether there
are enough of them present to make a formal decision.
</p>
<h3><i>The Role of OASIS</i></h3>
<p>
OASIS provides the electronic and organizational infrastructure
for TCs, but it does not in the general case contribute
resources, track different initiatives, or make policy; that
comes from the "interested parties" who stand to benefit from
the work. The role of OASIS in the TC process is to provide for
mailing lists, maintain archives, enforce the rules, and
otherwise stay out of the way.
</p>
<h2>The OASIS Standards Process</h2>
<p>
The factors outlined above are designed to enable the OASIS TC
process to operate at a speed appropriate to the collaborative
development of standards for an Internet economy. But the need for
rapid standards development has not diminished the traditional
requirement for wide implementation and careful industry-wide
review. The OASIS standards process achieves these seemingly
contradictory goals through a two-phase mechanism. The first phase
quickly delivers something that can be implemented; the second
phase asserts that the specification has been adopted widely enough
and successfully enough to become a real standard.
</p>
<h3><i>Phase One: Committee Specification</i></h3>
<p>
In the first phase, a TC consisting of individuals (that is,
persons holding individual memberships or employees of OASIS
member organizations) creates working drafts that eventually
become Committee Specifications. Working drafts require
just the approval of a simple majority of the TC membership,
but Committee Specifications require near-unanimity. A
Committee Specification, therefore, represents the consensus
of a group of experts working under the procedures set forth
in the process. If this level of review is sufficient for
the purposes of its users, a CS may be used without further
standardization. It is this first phase of the process that
can in theory be accomplished in 45 days.
</p>
<h3><i>Phase Two: OASIS Standard</i></h3>
<p>
If a Committee Specification has achieved general acceptance,
and if it meets certain other formal criteria specified by the
OASIS process, then it may be placed before the OASIS membership
as a Proposed Standard. Voting on a Proposed Standard is not
done by individuals but rather by the members of the corporation
itself, i.e., by the member organizations that are entitled to
cast votes in electing the Board of Directors.
It is the organizational
members who determine whether something is sufficiently
implemented and trusted within an industrial sector to become a
Standard.
</p>
<p>
A brutal but effective two-pronged criterion is used to
determine whether a Proposed Standard makes it through the
three-month review process. While it only takes 10 percent of
the OASIS organizations to approve a Standard, it also takes
only 10 percent
voting "no" to reject it. The effect is to make it
easy to approve a specification that has real support (even if
it's only within a single linguistic community as long as the
OASIS organizations approve the quality of the work) and equally
easy to disapprove a specification that any significant number
of people find to be ill-considered.
</p>
<p>
To sum up, the adoption of an OASIS Standard signifies that a
specification has received the approval both of a group of
individual industry experts operating at high speed, and then
of the OASIS member organizations considering the usefulness of
a Proposed Standard from an institutional point of view.
</p>
<h2>Conclusion</h2>
<p>
The OASIS TC process is intended to be as efficient as possible
while remaining legally accountable. Its implementation
constitutes OASIS as an organization for the rapid development of
open XML standards and puts the present and future control over
standards developed under the process firmly in the hands of those
who will have to use them. It must be remembered, however, that
the explicit trade-off of central control for speed and scalability
puts the burden of overseeing the development of such standards on
those same users, including in particular the commercial
organizations that have an interest in deploying them.
</p>
<h2>References</h2>
<p>
[1] <a href="http://www.oasis-open.org/committees/process.shtml">Technical Committee Process Overview</a><br>
(http://www.oasis-open.org/committees/process.shtml)
</p>
<p>
[2] <a href="http://www.oasis-open.org/who/intellectualproperty.shtml">OASIS Policy on Intellectual Property</a><br>
(http://www.oasis-open.org/who/intellectualproperty.shtml)
</p>
</body>
</html>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC