[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Corrected Minutes of Thursday 20 January, 2000
MINUTES OF THE REGULAR MEETING of the OASIS PROCESS ADVISORY COMMITTEE, 2000-01-20 The PAC met from 4:00 pm - 6:00 pm EST Thursday 20 January, 2000. Chaired by: Jon Bosak (bosak@eng.sun.com) Present were: Jon Bosak (bosak@eng.sun.com) Terry Allen (tallen@sonic.net) Robin Cover (robin@isogen.com) Eduardo Gutentag (eduardo@eng.sun.com) Deborah Lapeyre (dalapeyre@pop.mindspring.com) Lauren Wood (lauren@sqwest.bc.ca) The minutes of the previous meeting were approved as amended, with the date of February 8, 2000 being changed to February 28, 2000. Resolutions 1. The major business of the meeting was the continuing refinement and revision of the OASIS technical committee procedures requirements document. The document is appended to these minutes as Attachment 2. Jon Bosak moved that the committee adopt this document as amended. AYE 6 NAY 0 2. As previously resolved, we adjourned until the next regularly scheduled meeting to be held on Thursday, 2000.02.03 (4-6 pm EST) Meeting adjourned 6:00 pm EST. Deborah A. Lapeyre Secretary, OASIS Process Advisory Committee ================================================================== Attachment I Action Items 1. Terry Allen - will investigate whether this committee can invite non-members to participate in the phone call meetings and, if it can be done, describe the procedure. 2. Debbie Lapeyre - will send email to Murray Maloney in an effort to determine if he is still interested in participation and to urge him to attend the next meeting. ================================================================== Attachment II Design Principles for OASIS Committee Process RQ 1. Use cases The set of use cases to be employed in the OASIS process consists of all the cases that can be generated by each possible combination of "operation," "origination," "organizational scope," and "individual participation" below. With possibly a few anomalous exceptions, these cases are typical of those that will have to be handled by the OASIS process. The set is not intended to exhaust all the possibilities but rather to indicate the minimum set of cases that the system must be able to handle. OPERATION Note that a revision to a specification can be considered a specification. 1. Create a specification proposal (including requirements, if any) 2. Create a draft specification 3. Advance a draft specification to the status of a specification 4. Take over the creation of one or more draft specifications 5. Harmonize overlapping specifications, some of which may be complete and some of which may be in progress, by creating a specification or suite of specifications 6. Evaluate a specification 7. Maintain a specification 8. Advance a specification to the status of a standard 9. Maintain a standard ORIGINATION a. Requested by a vote of the OASIS membership b. Requested by OASIS members as individuals c. Requested by an OASIS committee d. Requested by the OASIS board e. Requested by some individual or group outside OASIS SPONSORSHIP a. OASIS b. Collaborative [Open question: whether OASIS standardization of a collaborative effort requires a formal vote of all the collaborating organizations.] PARTICIPATION a. OASIS members b. Members of an organization that is collaborating with OASIS c. Invited experts RQ 2. Resource/funding model The creation of OASIS technical committees should not be limited by the resources of OASIS as a corporation. RQ 3. Process phases The number and variety of possible use cases will require multiple entry points into the process, so that, for example, the same procedure for standardizing a specification can be applied regardless of the origin of the specification. To accommodate this requirement, the process must be divided into clearly defined phases with specified inputs and outputs. This modularity can yield beneficial side effects. 1. Dividing the process into phases makes it possible to assign people with different skills and interests to different parts of the process. In particular, the separation of charter and work phases allows problems to be stated by business experts and solutions to be designed by technology experts. 2. Transitions between process phases provide checkpoints at which projects can be reported upon and reassessed, thus, for example, discouraging the continuation of failed projects from simple inertia, or enabling the reinitialization of a phase. RQ 4. Process outcomes A TC's final products include: 1. A report to the agency that created the TC 2. A technical specification (unless the committee fails, in which case its only deliverable is a report) Elevation of a specification to the status of an OASIS standard is an action separate from the approval of a specification by a TC. A vote to approve a specification is a vote of the individual members of the TC, whereas a vote to standardize a specification is a vote of the members of OASIS. The nomenclature used for specifications and standards is illustrated by the following examples, which assume the existence of a fictional OASIS Footware TC. (Note that Draft Standards may originate outside OASIS.) Intermediate work products of the TC The Shoe Draft Specification of the OASIS Footware TC The Boot Draft Specification of the OASIS Footware TC Final work products of the TC The Shoe Specification of the OASIS Footware TC The Boot Specification of the OASIS Footware TC Results of later actions by OASIS as a whole (assuming for purposes of illustration that OASIS rejects Boot and accepts Shoe): The Rejected Boot Specification of the OASIS Footware TC The OASIS Shoe Draft Standard The OASIS Shoe Standard ================================================================== Deborah A. Lapeyre Secretary, OASIS Process Advisory Committee ====================================================================== Deborah Aleyne Lapeyre mailto:dalapeyre@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9633 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ====================================================================== ====================================================================== Deborah Aleyne Lapeyre mailto:dalapeyre@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9633 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC