xml-dev - Re: Who will maintain SAX?

[Jon Bosak <bosak@boethius.eng.sun.com>]

Since the maintainance of SAX is exactly the sort of project that
the new OASIS TC process was designed for, and since I chaired the
committee that recently finished designing that process, I guess
I'm going to have to take the position that this work should take
place in OASIS.  :-)

Please remember that I only subscribe to the digest version of
xml-dev and therefore can't respond instantly to replies.

Basically, the OASIS process is designed to allow the
standardization (in the official sense of the word) of an
unlimited number of XML specifications, each addressing a
particular vertical industry need or horizontal functionality.
The groups that produce these specifications are called technical
committees (TCs).

The TC process is described in detail at

   http://www.oasis-open.org/committees/process.shtml

The key points are as follows.

   1. There can be as many TCs as you want; the process is
      infinitely scalable.

   2. To make the process infinitely scalable, each new
      participant must ante up a sum sufficient to cover the
      incremental cost to OASIS of supporting the TCs in which
      they will likely participate.  This infrastructure support
      cost is levied in the form of annual dues (USD 250 per
      person for individual memberships).  A person who has paid
      the annual dues can participate in any OASIS TC.

   3. TCs run themselves.  OASIS has no say in their creation or
      operation; it just creates TC mailing lists and archives
      when requested by OASIS members and stands by to ensure that
      everyone follows the process.  If two or more TCs think they
      need coordination, they can form something called a JC
      (joint committee) to work it out.  Otherwise, no one bothers
      them as long as they adhere to the process.

   4. For every OASIS TC:

      a. The members who propose the TC determine its charter and
	 its chair.

      b. You always know who the members are.

      c. The members always know when they've made a decision.

      d. Only the members can decide to revisit a decision.

   5. The TC process can be run through phone conferences and
      email; face-to-face meetings are optional.  A significant
      amount of formal decision-making can take place entirely
      through email.

   6. The TC process is radically open.  All TC list archives are
      world-readable, so the whole world can see what's going on
      and can comment on it.  Any dues-paying OASIS member (or
      employee of an OASIS member organization) can become a
      member of any OASIS TC.  Anyone in the world can form a
      discussion group outside of OASIS to read and comment on the
      work of the TCs.

   7. The process for standardizing a specification produced by a
      committee is optional and completely separate from the
      process for producing the committee specification itself.
      Thus, it would be possible for a SAX TC to operate
      indefinitely without ever advancing the work further up the
      standards chain by seeking approval from OASIS as an
      organization.

In sum, OASIS TCs are autonomous bodies staffed and directed by
people interested in solving a particular problem in a fair and
open way.  The role of OASIS in the TC process is simply to
provide administrative and infrastructure services, and OASIS
member dues are set at a level that pays for those services.

As most readers of this list are aware, OASIS has had a lot of
trouble maintaining its infrastructure services this year.  I am
not (and frankly don't want to be) privy to the business dealings
of OASIS as a nonprofit corporation, but my impression from a
distance is that OASIS made some bad choices about service
providers.  The failure of at least one of those providers caused
some serious damage from which it will take a long time to
recover.  But the services are now outsourced to more dependable
providers, and there seems to be no reason to believe that the
quality of service won't be sufficient to meet the needs of TCs
created under the new process going forward.

The OASIS TC process is, to the best of my knowledge, the least
bureaucratic, least hierarchical, most open formal standardization
process in existence.  So if we need a formal standardization
process for SAX maintenance, I think this is our best bet.  It's
clearly better than any of the alternatives.

The interesting question is whether we need a formal process for
SAX maintenance.  I'm already on record in this forum as saying
that we do.  My main reasons are these:

 - If we don't put SAX in the hands of an open standards body, it
   will, at best, end up in an expensive, closed vendor
   consortium, or at worst, be defined by vendor implementations.

 - If SAX is not maintained through a formal process with clearly
   understood rules, a lot of other standards efforts will be
   prevented from citing it normatively.

I've been around long enough to find these reasons compelling.

So here's my recommendation.

   1. Find three or more people who are already OASIS members (or
      employees of OASIS member organizations) and are willing to
      serve as the voting members of a SAX TC.  There are probably
      a hundred people on this list who are already eligible to do
      this.

   2. Allow those people to select a chair, draw up a statement of
      purpose, and set a meeting schedule.  (The three or so
      people who sign up to be voting members are required to meet
      at least once a year by phone.)

   3. Write down the information required for the creation of a TC
      as described in the OASIS TC process (see URL above) and
      submit it to Karl Best.  Karl will check off the required
      information and will create a mailing list and a comment
      list for the SAX TC as mandated by the process.

   4. Hold the first meeting of the SAX TC.  The meeting can take
      place by phone or in person.  The voting members of the TC
      will be the people who have paid their dues and who show up
      (after properly notifying the chair) at the first meeting.
      At that point, the TC can appoint one or more people to be
      editors of the spec.

   5. After the SAX TC is properly constituted, continue to hold
      SAX technical discussions in xml-dev.  Only the voting
      members of the TC will be able to make formal decisions, but
      since the style of this group is to make such decisions
      rarely, the TC will rarely need to act.

Voila, you now have a completely legal formal process for
maintaining SAX that can continue operating pretty much the way
that it has been operating.  To me, this seems like the best
outcome.

Jon