XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.

advertisement

A Scalable Process for Information Standards

January 17, 2001

"As a practical matter, the ability of industry to develop coherent semantic standards depends on the health of the standards process."
-- Scaffolding the New Web: Standards and Standards Policy for the Digital Economy (RAND Science and Technology Policy Institute, 2000)

The Need for an XML Standards Organization

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).

An SDO for XML specifications should ideally have the following qualities.

  1. It should legally exist. In practice, this means that it should be incorporated, preferably as a nonprofit organization.
  2. All intellectual property developed by the organization should be made available to the public under a nondiscriminatory license allowing free use.
  3. Authority for governance of the organization should be vested in its voting members.
  4. 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.
  5. The organization should be governed by a formal democratic process.
  6. The formal deliberations of the organization should be archived and publicly visible.

OASIS as an Internet-speed SDO

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].

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.

High-speed Distributed Standards Development

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.

Self-Organization

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.

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.

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.

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.

"Interested Parties": The Invisible Hand

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.

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.

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.

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.

Using Technology to Streamline Standards Development

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.

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.

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.

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.

Majority Rule

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.

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.

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.

The Role of OASIS

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.

The OASIS Standards Process

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.

Phase One: Committee Specification

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.

Phase Two: OASIS Standard

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.

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.

Resources

OASIS Technical Committee Work

The OASIS Process for Structured Information Standards

XML, Standards and You

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.

Conclusion

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.

References

[1] Technical Committee Process Overview
(http://www.oasis-open.org/committees/process.shtml)

[2] OASIS Policy on Intellectual Property
(http://www.oasis-open.org/who/intellectualproperty.shtml)