Jon Bosak on 'Who will maintain SAX?'

Date:      Wed, 04 Oct 2000 10:52:02 -0700 (PDT)
From:      Jon Bosak <bosak@boethius.eng.sun.com>
To:        xml-dev@lists.xml.org
Subject:   Re: Who will maintain SAX?

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.

There can be as many TCs as you want; the process is infinitely scalable.
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.
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.
For every OASIS TC:
1. The members who propose the TC determine its charter and its chair.
2. You always know who the members are.
3. The members always know when they've made a decision.
4. Only the members can decide to revisit a decision.
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.
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.
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.

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

Prepared by Robin Cover for The XML Cover Pages archive.

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	Jon Bosak on 'Who will maintain SAX?' Date: Wed, 04 Oct 2000 10:52:02 -0700 (PDT) From: Jon Bosak <bosak@boethius.eng.sun.com> To: xml-dev@lists.xml.org Subject: Re: Who will maintain SAX? 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. There can be as many TCs as you want; the process is infinitely scalable. 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. 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. For every OASIS TC: The members who propose the TC determine its charter and its chair. You always know who the members are. The members always know when they've made a decision. Only the members can decide to revisit a decision. 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. 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. 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. 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. 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.) 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. 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. 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 Prepared by Robin Cover for The XML Cover Pages archive.