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


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

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

Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary


OK - now I understand this better - after your note vis external files as compared to pasted in the doc or pdf.

There appears to be two camps on this:

a) documentation automation - some TCs have their entire spec's in XML and run scripting to generate the external files from the actual documentation.

b) documentation separation - people embedding any formal XML in the specifications will be severely dealt with!  All formal angle bracket artifacts shall be packaged external and referenced accordingly from the written spec's.

I confess I'm in camp b) as the lowest common denominator.  Therefore the approval process needs to be able to iterate on the XML artifacts as a separate cycle from the written documents - to account for bug fixes and ooops events that are distinct from and require no changes to the written documents.

Thanks, DW

-------- Original Message --------
Subject: Re: [chairs] Draft Jan 2009 TC Process changes summary
From: Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
Date: Fri, January 08, 2010 1:45 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc: chairs@lists.oasis-open.org

hi dave,
Before we get into a long debate, let me point out that this term
is only internal to the OASIS Process - we just needed a name to use
as a referent - cold have been foobar, and in fact it was "orange" for
quite a while. AFA the world is concerned we just adding "Committee
Note" the list of thingies that can be approved by TC's and OASIS. (In
addition to CD, CS, OASIS Candidate Specification, OASIS Standard,
Public Review Draft).

Normative/non-normative is not appropriate in this case because:
1. Normative has a very precise definition and use in the OASIS IPR
policy; and
2. There can be lots of non-normative material in standard, which are
not required for conformance.


On Jan 08, 2010, at 10:28 AM, David RR Webber (XML) wrote:

> Jeff,
> This all makes sense - except what you are calling "non-standard"
> I'm used to referring as non-normative supporting materials. I.e.
> materials that are not required for conformance to the formal
> specification, but assist in the understanding and implementation
> thereof.
> I believe it may be clearer to use the term non-normative; or maybe
> even just "supporting materials".
> Non-standard - at least for myself - has the connotation that
> somehow the material in question is somewhat dubious, formative or
> unproven in nature.
> Thanks, DW
> -------- Original Message --------
> Subject: [chairs] Draft Jan 2009 TC Process changes summary
> From: Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
> Date: Thu, January 07, 2010 10:45 pm
> To: chairs@lists.oasis-open.org
> Hi,
> The Process Committee is proposing some additions and modifications
> to the TC Process and is soliciting feedback and comments on this
> "almost" final draft. I've tried to summarize the major and minor
> changes in this email, but you should read the real docs (attached) if
> you'd like to see the detailed changes.
> A major focus of the Process Committee for the last two years has been
> to add a "non-standards TC approval" track to the process. There were
> conflicting requirements involving trade-offs between IPR Policy,
> approval processes, reviews, etc. The result which you see before you
> is not quite as delicate a compromise as that surrounding the current
> US health care debates, but its close. :-) I've broken down the
> changes into 3 major components, but please keep in mind that they
> interact with each other, and that they are intended to work together.
> (I've always wanted to use the phrase "synergistic changes" but i will
> refrain.)
> The plan is to consider these changes at the next Board f2f meeting
> at the beginning of February, so we'd like to have feedback and
> comments available by January 25 ( a week or so before the Board
> meeting) so that they can be considered by the Process Committee and
> the Board.
> Attached you will find a redline showing the changes from the
> current policy, and a clean copy. The current policy is on the OASIS
> web site.
> Thanks and appreciation are due to Mary McRae (the OASIS TC admin) for
> a yeowoman's job in editing the TC Process doc, and keeping up with
> the various gyrations, drafts, and proposals that the Process
> Committee have produced, debated, thrown away, and finally settled on.
> Disclaimer: Also please note that this email is MY attempt, as TC
> Process Chair, to describe the changes and has not been formally
> approved by the TC Process Committee. (And I'm sure its members will
> chime in with their own comments if they are so moved. ;-)
> cheers,
> Jeff Mischkinsky, Chair, OASIS Board TC Process Committee
> ==============
> A)
> ------------------------------------------------
> The Public Review requirements for TC level approvals have been
> simplified and streamlined, partially to accommodate the addition of a
> non-standards track.
> Basically the minimum for initial public review will be 30 days (down
> from 60 days) with subsequent reviews being at least 15 days. ANY
> changes made after a review closes must be submitted again for public
> review.
> Section 2.18 has been split to distinguish between Committee Spec (no
> change) and Committee Notes (new)
> COMMITTEE NOTES aka "non-standards track work product", aka "info
> docs" (Section 2.18 B and 3.3)
> ---------------
> The Process Committee has been working for almost 2 years to add a
> "non-standards" TC approval track.
> The basic idea is that we've added a means whereby TC's will be able
> to approve as a Committee Note any material that is not intended to be
> a standard. These could be primers, explanatory material, best
> practices (how to use a standard), presentations/papers, test suites,
> etc., that can be "officially" approved as representing the views of
> the TC, etc. They will be covered by the IPR policy. The mechanics of
> the approval process are the same as for a Committee Specification so
> that there is no incentive to classify something as standards track
> vs. non-standards track because one is easier to get approved, i.e.
> can't "game the system".
> A non-standards track work product stops at the Committee Note level.
> Therefore it may NOT be put up for an OASIS-wide vote, unlike a
> standards track work product, nor submitted to an outside (de jure)
> body.
> Committee Notes will have different templates, cover pages, etc. to
> distinguish them from specifications/standards. They are not intended
> to be normatively referenced by other standards (either inside or
> outside of OASIS), though of course there is no way to actually stop
> someone from doing so (hence the IPR safeguards and rigorous review/
> approval process).
> A TC can choose to "re-target" a work product by deciding to switch
> templates and going back to the CD stage.
> Section 2.18 B, which is new, describes the required parts of
> Committee Note. Essentially they are the same as for Committee Specs
> except that a Conformance Clause (B1) and external files for
> programming language artifacts (B5) are optional.
> -------------------------------
> The process from going from Committee Spec to OASIS standard has been
> modified. We've identified a new state for a Committee Spec that a TC
> wishes to advance to OASIS Standard, called a Candidate OASIS Standard
> to clarify things.
> The main change is to now require a 60 day public review of the
> Candidate OASIS standard, to ensure that OASIS standards that are
> submitted for international (de jure) standards processing meet their
> review requirements. This replaces the "familiarization period" under
> the current policy. Candidates may now be submitted at any time (not
> just once a month) and TC admin now has at most 15 days to complete
> processing and start the Public Review.
> Once the public review has completed, there are now shortened
> timelines for conducting the subsequent approval votes. The possible
> outcomes of the public review (no comments, comments but no changes
> made as a result, changes made as a result) and the subsequent
> processing rules have been clarified.
> Note: The minimum time lines for the public reviews and votes should
> be approximately equal to get to OASIS standard and shorter for
> Committee Spec under the new system.
> =======================
> The Process Committee is going to recommend that non-standards track
> be added "immediately", where "immediately" means something like the
> beginning of the month following Board approval. Changes to currently
> "in flight" standards track documents will be phased in so that work
> product that is currently "close" to being approved will be subject to
> the old rules. The exact definition of "close" contained in the first
> para of Section 3.4 are still somewhat tentative. (I think it is safe
> to say they would only be loosened, not tightened.)
> ==================
> 1. Uniform 7 day membership deadline for initial TC meeting whether
> f2f or telecon. (2.3)
> 2. Clarified requirements for comment processing and made clear that
> once a doc is out for public review if someone discovers a major
> "oops" that requires a change before the review period ends, then it
> must be withdrawn and resubmitted for a new public review (if the TC
> so desires). (3.2 2nd and 3rd para)
> 3. Clarified requirements around which versions of oasis templates to
> use. (3.4.1)
> 4 Clarified rules around the mechanics of OASIS standard
> ballots(3.4.3)
> 5. Various other more minor clarifications, editorial changes, etc.,
> some of which i've probably missed in the above list.
> --
> Jeff Mischkinsky jeff.mischkinsky@oracle.com
> Sr. Director, Oracle Fusion Middleware +1(650)506-1975
> and Web Services Standards 500 Oracle Parkway, M/S 2OP9
> Oracle Redwood Shores, CA 94065

Jeff Mischkinsky jeff.mischkinsky@oracle.com
Director, Oracle Fusion Middleware +1(650)506-1975
and Web Services Standards 500 Oracle Parkway, M/S 2OP9
Oracle Redwood Shores, CA 94065

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