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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

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


Subject: Testing and CS votes - thoughts from the OpenCSA Steering Committee


hi,
   At todays OpenCSA Steering Committee meeting we discussed criteria  
for approval and progression of the specs vis a vis testing/ 
implementation requirements.

  We passed the follow motion unanimously:
    [The OpenCSA ] Steering Committee Recommends inclusion of the  
completed test suite with the main package for the initial CS vote.

I've also included some of the discussion/background to set the  
context and let you see what our thinking is. The full minutes are, as  
always, available in the OpenCSA Member Section email archives.



         DISCUSSION:

         Technically the Steering Committee doesn't have approval
         rights for Committee Specifications.  The TC's have the
         right to decide when they go to Committee Specification
         status.  The most we can do is to make a recommendation
         to the TC's.

         We could get bottoms up feeling on this.
         We could also recommend that testing should have started
         by CS time frame so that the TC has a higher level of
         confidence in the CS. (i.e. at least some sanity testing
         of some sort).

         OASIS is missing is the Call for Implementation stage that
         other groups such as the W3C has.

         There is benefit to using the first CS as similar kind of
         CR level. If we try to push for stuff that is too stringent
         (from a testing standpoint) at this stage we might get
         pushback.  We don't have power to do that.

         We should be pushing the message that the TC's should
         treat the first CS as "we think that we are done, now
         it's time to debug with some implementations to validate
         the specification".  The CS provides another higher
         level of stabilization for the specification. This
         should help encourage people to take the risk of
         implementation.

         The test suites (artifacts) really should be complete
         before CS and they should be approved as part of the
         CS process as well. The Steering Committee should make
         a recommendation that the TC's go for Test Suite and
         main spec approval at the same time.

         Additional Discussion:
         Should we add something along the lines that we expect
         there would be a subsequent CS once the testing requirements
         are met? e.g. Before you can go to OASIS std vote. You have  
to have
         a CS...

         This is already part of the OASIS rules and therefore
         doesn't need to be said again.  In general the OASIS
         process requires that a ballot be done on whether to
         submit a CS to Membership consideration as a standard.
         The other option is to iterate through the CD, PR,
         CS cycle again if there are substantive changes found
         by testing or even field comments.

cheers,
    Jeff Mischkinsky
    Chair, OpenCSA Steering Committee

--
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]