OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [uddi-spec] Comments on Process Document






Hi John,

Yes - I see your point.   The intent was not to make this overly complex,
but just to define the basic structure and operational behavior needed for
the TC to effieciently develop specifications.  The basic principles I see
as important are:

- Ability to delegate work to subcommittees, whenever appropriate
- Creation of specifications or specification components by subcommittees
- Assembly of overall specifications is performed by the TC (or its
delegate), formed by merging constituent contributions of subcommittees as
appropriate
- No spec. or spec. component goes forward from a subcommittee without
approval of that subcommittee
- No spec. or spec. component goes forward as a TC Specification without
the approval of TC (not just subcommittee)

The rest of the structure around these things separating the stages of
specification development into "Working Draft", "Candidate Draft" and
finally "TC Specification", was in my mind an attempt to go from what
starts as a simple, less controlled and dynamic environment, toward a more
controlled and finally very formal environment.   I'd agree that the way
this reads is way too confusing and doesn't get the points across well.
So I guess we fix it en-group as it were.  If you have some suggestions for
a revision, please post it.

Thanks,
Tom Bellwood       Phone:  (512) 838-9957 (external);   TL:  678/9957
(internal)
Senior Technical Staff Member
Emerging Technologies
IBM Corporation


John Colgrave <colgrave@hursley.ibm.com> on 09/23/2002 04:29:15 PM

To:    uddi-spec@lists.oasis-open.org
cc:
Subject:    [uddi-spec] Comments on Process Document



Below are the comments that I sent privately to Luc and Tom.

John Colgrave
IBM

I agree with most of Claus's comments and have not bothered to duplicate
the
typos etc.

I will focus on section 1 as I find it very confusing. To begin with, here
is a list of the various document types, with my acronyms for them, that
are
either mentioned or implied:
1 Requirements Specification (RS)
2 Subcommittee Working Draft (SWD)
3 TC Working Draft (TCWD)
4 Subcommittee Candidate Draft (SCaD)
5 TC Candidate Draft (TCCaD)
6 Subcommittee Committee Draft (SCoD) - an oxymoron I know
7 TC Committee Draft (TCCoD)
8 Committee Specification (TCS)
9 OASIS Specification (OS)

Is it assumed that at least one subcommittee will always be required, or
can
the TC produce specifications directly? Let us assume that for a given
specification, 2 subcommittees are required to produce the working drafts,
S1 and S2. Their documents will be named accordingly. I will try and spell
out what I think section 1 is saying and you can correct as necessary.

a) The TC gathers, refines etc. the requirements and produces the approved
RS.

b) The TC creates S1 and charters it to provide S1WD.

c) The TC creates S2 and charters it to provide S2WD.

d) S1 produces S1WD and votes on it. Section 1.3 says that the subcommittee
votes to advance this to TCWD status but that can't be right as the TCWD is
produced from both S1WD and S2WD. I think we should say that the
subcommittee votes to submit S1WD to the TC for approval and inclusion into
the TCWD.

e) S2 produces S2WD and votes to submit it to the TC.

f) Can the TC reject/return S1WD and/or S2WD? Assuming it does not do so in
this case, the TC combines S1WD and S2WD to form the TCWD. Does it do this
directly or form a different subcommittee to do it?

g) Section 1.4 says that Candidate Drafts are prepared by the TC or a
subcommittee. Do we need to say why one option might be chosen over the
other? What is the preparation involved? Section 1.3 just talks about the
TC
voting to advance the TCWD to TCCaD status. In this case, assume the TC
decides to create two subcommittees S3 and S4 to produce the Candidate
Draft.

h) The TC creates S3 and charters it to provide S3CaD.

i) The TC creates S4 and charters it to provide S4CaD.

j) S3 produces S3CaD and votes to submit it to the TC for consideration.

k) S4 produces S4Cad and vodes to submit it to the TC for consideration.

l) The TC votes on S3CaD and S4Cad and approves them. They are merged into
the TCCaD either by the TC directly or by yet another subcommittee.

m) The TC forms two different subcommittees, S5 and S6 to evolve the
Candidate draft.

n) S5 produces S5Cod.

o) S6 produces S6Cod.

p) The TC accepts these and, either itself or in a subcommittee, merges
these to produce the TCCoD.

q) The TC votes to release the TCCoD for public review.

r) The TC votes to move the TCCoD to TCS status.

s) OASIS votes to move the TCS to OS status.

I may have missed a few steps but I am sure you get the idea! The number of
stages and the bouncing around between the TC and subcommittees is
incredibly confusing.

I think we need to say more about what happens if/when any of these votes
fails.


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
 manager: <http://lists.oasis-open.org/ob/adm.pl>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC