With other rules with which we're familiar, the process is actually
to first create an identifiable package in the archive that
satisfies the changes described, then the sequence below. "A vote to
amend the package" is simply a formal approval vote of the
replacement package.
While the effect is to correct the typos in the two schema files,
the result is a single package as per the multi-part work product
rules.
Thanks for the clear description, Robin!
bill cox
--
On 4/26/11 7:45 PM, Considine, Toby (Campus Services IT) wrote:
49388A5276025649AC24AF97ADB9DA627127240D71@facmailmb3.facilities.unc.edu"
type="cite">
The problem is clarity on one side is not clarity on the other.
So:
- The TC (internal vote) votes to amend the package by using these specific updated artifacts.
- The TC (external vote) then petitions the TC Admins to use the amended package for the public review as previously scheduled but not yet instantiated
This gives the necessary precision internally, and the necessary single approval for the TC Admins
"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 7:36 PM
To: Robin Cover
Cc: Considine, Toby (Campus Services IT); emix@lists.oasis-open.org; Chet Ensign
Subject: Re: [emix] Groups - emix-1-0-schemas-wd23-corrections.zip uploaded
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
|