emix — archive

[Robin Cover <robin@oasis-open.org>]

On Tue, 26 Apr 2011, Anne Hendry wrote: > I'm talking only about the vote only. > The vote is to approve changes specifically to those two schemas (within the package). > > I guess you can look at it as clarifying the word 'corrected' in your original statement: > > ?The TC approve the corrected schemas, > and direct the TC Administrator issue the Public Review using the corrected schemas?   > > specifically stating what was corrected. > > If you're giving them an entirely new package then the last part of that sentence should probably be > "... and direct the TC Administrator issue the Public Review with an updated package containing the (or these) corrected > schemas? > > The TC Admin may have some input/requirements on the terminology for this. > > -A > > Considine, Toby (Campus Services IT) wrote, On 4/26/2011 2:05 PM: > > That is correct. Only those two schemas, with the diffs, are changed. > > As for the motion to the TC-Admin, it is my sense that they prefer to receive a single package, rather than direction to replace one, keep the next, replace a third, etc. The TC is welcome to craft motions of any kind about asking/directing TC Admin to (please) do such-and-such, but the relevant rules for approval motions are not a matter of TC Admin preference. They are outlined in definitions from the TC Process and in rules about approval motions for constituent elements in multi-part works. - Work Product Approval Motion - Work Product Ballot - Multi-Part Work Product I think the following write-up (composed originally for use elsewhere) should provide all the references and commentary on how to frame a motion/ballot for a Work Product approval. Short version: identify and address the Work Product as a whole (single entity) in the Work Product ballot. Cheers, - Robin ==================================================================== Multi-Part Works and Motions/Ballots for Approval The TC Process recognizes that most specifications (called "Work Products) are "Multi-Part" in that they are represented by a whole made up of constituent parts, where "parts" are files or logical groups of files functioning as storage objects for a conceptual unity ("part"). There is no notion of "set" relations but there is a strong notion of part-whole. It is essential to know exactly, and at all times, what parts (files) are constitutents of the whole. TC Process: "Multi-Part Work Products. A Work Product may be composed of any number of files of different types, though any such multi-part Work Product must have a single Work Product name and version number. Irrespective of the number and status of the constituent parts, the Work Product as a whole must be approved by a single Work Product Ballot." http://www.oasis-open.org/committees/process.php#quality-multiPart http://docs.oasis-open.org/TChandbook/Reference/WPQualityRequirementshtml#multi-part The "parts" are allowed to instantiate almost any mixture of document types: prose documents, XML schema files, image files, formal language definitions of other types, code, or other machine-readable or human-readable artifacts. The key point to understand is that a specification must be treated **AS A WHOLE** with respect to motions, votes, and ballots that represent acts of approval by the TC. Similarly, when an approved work product at some level of maturity is published as an approved instance (release), all parts must be identified and included in the publication. No constituent part may be advanced separately (e.g., for public review) and no part may be excluded from an approval event. A ZIP file should be used to package all the parts. All parts are to be included in the publication. All parts are also considered to progress together with the same Stage identifier and Revision number at all times -- whether or not all parts are equally mature from a technical point of view. Some parts may have changed dozens of times in the past few weeks (or since the previous CSD or CSPRD) and some parts may not have changed at all. Irrespective of change history and technical maturity, all parts much be considered as part of the whole for any revision/stage. That means all the parts must be considered as belonging to the whole at all times. The TC could not vote to approve "Part 1" at CSD02 level, then as CSPRD, while leaving Part 2 to the side at CSD01 level. Note that some files might be edited more often than others (e.g., in the SVN repository), but with respect to official actions of the TC to approve something, the same approval event must cover the specification as a whole, including all parts. A Work Product Approval Motion is any motion to initiate a Work Product Ballot. A Work Product Ballot is any TC ballot for the approval of a Committee Specification Draft or Committee Note Draft, for start of a Public Review, for approval of a Committee Specification, or a Committee Note, or submission of a Committee Specification as a Candidate OASIS Standard.... http://www.oasis-open.org/committees/process-2010-07-28.php#WPapproval http://www.oasis-open.org/committees/process-2010-07-28.php#dWPballot =================================================================== Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/who/staff.php#cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 > > > > > "It is the theory that decides what can be observed." - Albert Einstein > > Toby Considine > Chair, OASIS oBIX Technical Committee > U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee > Facilities Technology Office > University of North Carolina > Chapel Hill, NC > > Email: Toby.Considine@ unc.edu > Phone: (919)962-9073 > http://www.oasis-open.org > blog: www.NewDaedalus.com > > >