Re: [emix] Groups - emix-1-0-schemas-wd23-corrections.zip uploaded

[Anne Hendry <ahendry@pacbell.net>]

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: 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
>>
>>
>> -----Original Message-----
>> From: Anne Hendry [mailto:ahendry@pacbell.net] Sent: Tuesday, April 
>> 26, 2011 4:56 PM
>> To: Considine, Toby (Campus Services IT)
>> Cc: emix@lists.oasis-open.org
>> Subject: Re: [emix] Groups - emix-1-0-schemas-wd23-corrections.zip 
>> uploaded
>>
>> Hi,
>>
>> Just to clarify, there aren't any changes to the spec, just to the 
>> two schemas, emix-requirements.xsd and power-products.xsd?
>>
>> If so, perhaps we should include the two schema names in the motion 
>> so that people that have already downloaded the earlier package know 
>> where to look for changes:
>>
>> ?The TC approve the corrected schemas, emix-requirements.xsd and 
>> power-products.xsd, and direct the TC Administrator issue the Public 
>> Review using the corrected schemas? ?
>>
>> Otherwise there's no specific info in the motion about which schemas 
>> have changed ...
>>
>> -Anne
>>
>> toby.considine@unc.edu wrote, On 4/26/2011 12:36 PM:
>>
>>
>>  The document named emix-1-0-schemas-wd23-corrections.zip has been 
>> submitted by Toby Considine to the OASIS Energy Market Information 
>> Exchange (eMIX) TC document repository.
>>
>> Document Description:
>> These are the technical corrections to the WD23 Schemas to address 
>> issues found while creating sample messages. If the TC accepts them, 
>> I will move that we use these as the PR02 documents. The set includes:
>> 1)    A complete set of schemas.
>> 2)    Documentation of the changes made (initially made while preparing
>> samples, then documented later) in txt and in pdf
>> 3)    Diff reports (prepared with DiffDog) showing before and after
>> emix-requirements and power-products
>>
>>
>>
>> View Document Details:
>> http://www.oasis-open.org/committees/document.php?document_id=41943
>>
>> Download Document: 
>> http://www.oasis-open.org/committees/download.php/41943/emix-1-0-schem
>> as-wd23-corrections.zip
>>
>>
>> PLEASE NOTE:  If the above links do not work for you, your email 
>> application may be breaking the link into two pieces.  You may be 
>> able to copy and paste the entire link address into the address field 
>> of your web browser.
>>
>> -OASIS Open Administration
>>
>>
>>
>>
>>