emix — archive

Groups - emix-1-0-schemas-wd23-corrections.zip uploaded

From: Anne Hendry <[email protected]>
To: [email protected]
Date: Tue, 26 Apr 2011 23:37:00 -0000

Thanks, Robin. My interpretation of this is we should use the same wording we used for the last vote on the entire package (no mention of 'schema' at all) either directly or otherwise, since the ballot has to be for the whole, not only for the corrected schemas ... -A Robin Cover wrote, On 4/26/2011 3:25 PM: > 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: [email protected] > 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 >> >> >>