Re: PAC: Revised language for CS 6

[Terry Allen <tallen@sonic.net>]

I regret I've missed much discussion on this, and apologize if I've
failed to notice some of it in email.  I have a few questions.

| To: workprocess@lists.oasis-open.org
| Subject: PAC: Revised language for CS 6
| 
| The following reflects comments received on this subject so far.
| Since this has already received a fair amount of discussion, I
| will be moving to adopt the language proposed here in our meeting
| Wednesday.
| 
| Jon
| 
| ==================================================================
| 
| CS 6. Standards and Languages
| 
| OASIS TCs shall be authorized to work in any language they choose.
| The language of reference for a TC shall be declared at the same
| time its meeting schedule is first proposed.  Formal actions of
| TCs shall be governed by the same rules regardless of the language
| in which the work is taking place.  Administrators designated by
| the OASIS board shall be responsible for certifying compliance
| with procedural and technical criteria.
| 
| A TC that has approved and published a committee specification may
| simultaneously or at some later time recommend that the
| specification be made an OASIS standard.  Upon resolution of the
| TC to move the specification forward, its chair shall submit the
| following items to a designated representative of the board:
| 
|    1. A formal specification that is a valid member of its type
|       (if an XML schema, it validates; if source code for a
|       program module, it compiles; etc.).

Suppose it's a prose specification with a bit of EBNF.  Is that
not formal?  or is it etc.?

|    2. Appropriate documentation for the specification, written in
|       the language of reference.
| 
|    3. A clear English-language summary of the specification.
| 
|    4. Certification by the voting members of the TC that the
|       specification is copyrightable and publishable by OASIS and
|       usable by everyone without charge.  Standard language to
|       accomplish this objective shall be prepared by OASIS counsel
|       for use by all TCs.

I don't see how TC members can take a position on copyrightability
except by certifying that they know of no competing copyrights.
If OASIS is going to copyright, then how can the TC members 
certify that it's usable by everyone without charge?  I get the
drift here and I know this is not proposed amendment language,
but this all sounds backward (and I have no faith at all in the
OASIS counsel, having seen his work).

|    5. Certification by at least three OASIS member organizations
|       that they are successfully using the specification.
| 
|    6. An account of votes and comments received in any earlier
|       attempts to standardize substantially the same
|       specification, together with the originating TC's response
|       to each comment.
| 
|    7. A pointer to the publicly visible comments archive for the
|       originating TC.
| 
| [the next two paras have been changed from the previous draft]
| 
| Thirty days shall be allowed for administrative processing of a
| proposed standard.  The proposal shall be submitted to the OASIS
| membership for review at the beginning of the calendar quarter
| immediately following the 30 days allocated for administrative
| review.  At the beginning of the next calendar quarter, the
| proposal shall be submitted to the voting members of OASIS, who
| shall have one month to return a ballot approving or disapproving
| the proposal.

Who does the processing and submitting to membership?  staff?
And I recall some email from Eduardo about timing that I may
be repeating:  there is potentially 2 months of slack here
before submission to the membership; why is that?  or do you
mean "three-month period"?  (I think of there being four
"calendar quarters" only.)

| The TC that originated the specification may, by formal
| resolution, withdraw the proposed specification at any point after
| it is submitted to OASIS for administrative processing and before
| the end of the voting period.

Without explanation?

| In votes upon proposed OASIS standards, every OASIS member
| organization shall be entitled to cast one vote.  Individual
| members (whether the membership is transferable or
| non-transferable) shall not be entitled to vote in the approval of
| OASIS standards.
| 
|    [Note that this is intended to reflect the current OASIS
|    membership structure in line with our discussion.  Since the
|    existing bylaws already distinguish between voting and
|    nonvoting members, it would be logically equivalent to say
|    nothing at all on this point, but silence will almost
|    undoubtedly be misunderstood.  It would be clearer to say that
|    the voting members for purposes of this section are the voting
|    members in elections of the board of directors; this would be
|    very clean with regard to future changes to the membership
|    structure, but it would also allow this criterion to change if
|    (for example) some future revision of the membership structure
|    were to give individual members the right to vote in board
|    elections.  Here I have assumed that we consider a vote by
|    organizations rather than individuals to be fundamental to the
|    difference between the approval of a committee specification
|    and the approval of an OASIS standard.  Care will have to be
|    taken in drafting language for the revised bylaws to correctly
|    capture our intent.]
| 
| The results of a vote on a proposed standard shall be provided to
| the membership and to the TC no later than one week following the
| close of the voting period.
| 
| If a proposed specification has received no negative votes by the
| end of the voting period, it shall become an OASIS standard.

I'll have to vote against that (but then I won't be able to
if you vote on Wednesday...).  I think there must be some
minimum number of positive votes for the process to have any
credibility.

| If a proposed specification has received negative votes amounting
| to 10 percent or more of the voting membership of OASIS, it shall
| not become an OASIS standard.  This shall not prevent the same or
| similar specification from being submitted again for a vote of the
| membership.
| 
| If a proposed specification has received negative votes totaling
| less than 10 percent of the voting membership of OASIS, the
| negative votes and accompanying comments, if any, shall be
| forwarded to the originating TC for consideration.  After
| notification of the results, the TC shall have 30 days to take one
| of the following actions with regard to a submission that has
| received negative votes from less than 10 percent of the
| membership:
| 
|   (a) The TC may withdraw the submission.
| 
|   (b) The TC may resubmit an amended specification; in this case,
|       the amended submission shall be considered as if it were a
|       new submission, except that information regarding previous
|       votes and the disposition of comments received in previous
|       votes shall accompany the amended submission.
| 
|   (c) The TC may accept the submitted specification unchanged; in
|       this case it shall become an OASIS standard 30 days after
|       notification of the results.  This is the default outcome if
|       the TC takes no action within 30 days following notification
|       of the results.

(c) leaves matters in the hands of the TC rather than OASIS, as
I would expect, and requires no formal action by the TC.  So the
TC, not OASIS, makes the spec a standard, and silently.  That
feels wrong.  Shouldn't they at least vote if they're going to
do things this way?  and wouldn't it be better for OASIS to proclaim
the change of status to standard?  Surely the Board, or some
committee appointed for the purpose, could do that much.

regards, Terry