[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Minutes of Thursday 6 January, 2000
MINUTES OF THE REGULAR MEETING of the
OASIS PROCESS ADVISORY COMMITTEE, 2000-01-06
The PAC met from 5:00-6:50 pm EST Thursday 6 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)
Mary McRae (sgmlgeek@top.monad.net)
Tommie Usdin (btusdin@mulberrytech.com)
The minutes were read and amended; Deborah Lapeyre as Secretary agreed to
redo the initial minutes and redistribute.
Resolutions
1. Meeting Schedule
a. Meeting will 1 hour earlier for the next 10 weeks;
meetings will be held from 1:00 pm to 3:00 pm Pacific
(4:00 pm to 6:00 pm EST)
b. On March 16, 2000, the schedule will revert to
2:00 pm to 4:00 pm Pacific (5:00 pm to 7:00 pm EST)
c. The next three meeting dates will be:
20 Jan 4:00 pm - 6:00 pm (EST)
3 Feb 4:00 pm - 6:00 pm (EST)
17 Feb 4:00 pm - 6:00 pm (EST)
d. The timing and length of the face-to-face meeting
the week of March 2 will be reconsidered
at the next meeting.
AYE 7 NAY 0 Abstain 0
2. The major business of the meeting was the continuing refinement
and revision of the OASIS technical committee procedures requirements
document. The latest draft is appended to these minutes as
Attachment 2.
3. Resolved to adjourn until the next regularly scheduled
meeting to be held on
Thursday, 2000.01.20 (4-6 pm EST)
Meeting adjourned 6:50 pm EST.
Deborah A. Lapeyre
Secretary, OASIS Process Advisory Committee
==================================================================
Attachment I Action Items
1. Mary McRae - will obtain schedules for XTech'2000 and
any associated OASIS meetings, as input to the PAC
meeting schedule during the week February 8 - March 3,
2. John Bosak - will arrange the altered meeting times
with the telephone company
==================================================================
Attachment II RQ Draft in Progress
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
[Open question: whether a request that in fact comes from
outside OASIS is required to be submitted in the form of
a request by one or more OASIS members.]
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
************* continue reading here 2000.01.20 **************
RQ 2. Resource/funding model
The creation of OASIS technical committees should not be
limited by the resources of OASIS as a corporation.
This appears to imply that the incremental cost of creating a
TC should, on average, not exceed the incremental revenue
gained through the addition of members as a direct or indirect
result of creating the TC.
RQ 3. Process modules/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 whether the specification has been
developed by an OASIS TC or by some outside organization
requesting OASIS standardization status. The only way we can
see to accommodate this requirement is to divide the process
into clearly defined modules with specified inputs and outputs.
This "pipelining" architecture can yield beneficial side
effects.
1. Modular process phases make 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
discouraging the continuation of failed projects from simple
inertia.
RQ 4. Outcomes
The deliverables of a TC 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)
[Open question: What is the vote required for the
committee to approve a spec (as opposed to a working
draft)?]
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 voting
members of OASIS are typically organizations rather than
individuals.)
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.
Deliverables of the committee on its own authority:
The Shoe Draft Specification of the OASIS Footware TC
The Boot Draft Specification of the OASIS Footware 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
==================================================================
End document
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
======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC