TC coordination (was: Re: [chairs] OASIS given liaison membership atJTC1 SC34)

[Jon Bosak <Jon.Bosak@sun.com>]

Karl Best said:

| We also need to make sure that the various OASIS TCs are working
| together. We've set up a joint committee (JC) for the ebXML TCs,
| and likely will invite other e-business TCs to join. In the coming
| months expect to see some announcements related to our managing
| TCs as groups, by topic. None of this will effect the bottom-up
| member-driven approach; we will still allow members to set our
| technical agenda, and TCs will still control their own charters
| and agendas, but we want to encourage TCs to work together,
| jointly develop architectures, and make sure that all of our
| specifications interoperate.

I'm sorry, but if we're controlling the architecture, then we are
implicitly controlling the scope of the TCs.  There's no way
around that.

The OASIS TC process was designed to allow competition at the
specification level so that freely competing specifications could
be sorted and graded in a second phase run by different rules.  In
the OASIS process this second round is the standardization phase,
and it's here that OASIS as an organization is supposed to apply
the control that Karl is seeking to exercise at the specification
level.  In the standardization phase, OASIS as a corporation
decides which of the competing specifications gets to be a
standard based on the general quality of its design, its success
among implementors, and its acceptance by the general community.

The design center of the OASIS process is scalability.  The
process is designed to support an unlimited number of simultaneous
XML definition efforts without blowing up from the strain of
trying to coordinate them.  The process doesn't even require that
members of different TCs speak enough of the same language to
communicate with each other.  This allows valid OASIS
specifications to be developed within and for the use of an
unlimited number of natural language communities, thus fulfilling
an essential purpose of XML itself.

(Working out the implications of this language requirement for
efforts to exercise central control over the TCs is left as an
exercise for the reader.)

The OASIS TC process is a deliberately darwinian model in which
relatively few specifications are made standards.  It somewhat
resembles the IETF process in this respect.

The goal of coordinating the TCs is a good one.  It is certainly
true that willing coordination can aid interoperability.  Karl is
right in suggesting the formation of joint committees (JCs), since
this is exactly what JCs were designed for.  I applaud the call
for their formation wherever appropriate.  But everyone should
realize going into this that JCs are expressions of the desire of
the TCs to coordinate among themselves, not of the OASIS
administration's desire to achieve conformity to a single
architecture or framework.  The TC process requires that all of
the resources necessary to constitute a functioning JC have to
come entirely from the TCs desiring to cooperate, not from OASIS.
This part of the process was deliberately designed to keep the
process scalable.  And it means that JCs (which are procedurally
just extensions of the class of TCs) are themselves independent of
control and answerable only to their members.

The only workable alternative to federations of cooperating groups
is a hierarchical control structure.  Hierarchical structures are
very popular, and there are lots of organizations devoted to the
specification of (a relatively limited number of) standards that
use this method of control.  The OASIS TC process was designed by
a group of standards process veterans who collectively had decades
of experience doing XML and SGML standards work and were quite
familiar with the control structures of existing data standards
organizations.  They deliberately built the OASIS process in a
special way in order to deal with a special requirement -- the
need to support an unlimited number of specification groups
working at an unlimited speed using limited resources.

You can't exercise central control over such a thing without
breaking it.  The right way to control it is to filter the
resulting specifications at the level of the entire organization
and ratify only the few that gain general use and approval.  This
is the role of the standardization phase, not the committee
specification phase.

For more about the design principles underlying the OASIS process,
see

   http://www.xml.com/pub/a/2001/01/17/oasisprocess.html

| > OASIS should also have a policy that ensures there is inter-
| > operability within relevant and related technical committees
| > of OASIS.
| 
| While this is not a MUST in the normative TC Process, I've been
| treating it as a SHOULD in the non-normative TC Guidelines. Maybe
| I can get this changed.

We spent two years putting this process in place, and so far it
seems to be working very nicely within its design constraints.  It
would probably be best to leave the process alone for a while and
try out the coordinative mechanisms it already supports.

Jon Bosak
Chair of the OASIS Process Advisory Committee, 1999-2001