[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Re: [members] Please follow these steps to avoidproblems with your requests for TC Admin support
Few comments: 1) WRT the suggestion from Chet: "One option is to use the "Latest Version" link from the spec's front page in your cross-reference. This will resolve to the latest of the CSD's for the specific specification rather than to the published version at the time you approved your CSD. Your risk there of course is that the most recent CSD may have changes in it that you haven't accounted for in your spec - that is a risk you would need to weigh yourselves." I don't believe the normative reference format in the template allows that. The URL in the reference may point to the latest link, but the reference has to list the title, date and state/stage of the OASIS spec. 2) This is how the SCA-J TC is planning to deal with its reference problem (note there aren't any cyclic dependencies here, so the SCA-J TC doesn't need the DCRs; at least not yet): http://lists.oasis-open.org/archives/sca-j/201107/msg00029.html 3) I think between DCRs (if they are extended to CSDs; currently they are not) and allowing specs to reference other specs that are in the TCAdmin pipeline as outlined in (2) above, we should be able to solve our reference problems. I'm not in favor of using references to the 'latest'. Especially with the new OASIS policy in mind, of requiring at least a 15-day review if there is any change to the spec (other than front page matter). A change in reference may be a big deal for a spec. And it is not always easily apparent if it is a big deal or not for a particular spec unless you examine it closely. The referenced spec itself may not have changed except for maybe one of *its* references and so on -- it is turtles all the way down. Allowing a spec to reference the latest link of another spec is just asking for trouble IMHO. -Anish -- On 7/29/2011 2:47 AM, Simon Holdsworth wrote: > Chet, > > (including SCA Bindings TC on my response as this is the subject of > discussion at the TC). > > Thanks for the response. At least for the spec documents I am editor for > we have take the approach that the "related works" section contains > "latest" links and not links to specific versions, however the > "Normative references" section does have references to specific > versions. For links between specifications within the member section, > the expectation is that the reference is to that specific version or any > more recent, requiring the TCs to resolve any backward incompatibilities > and that such changes would require new CSDs with updated references. > > There's one remaining question I have which is probably best posed with > a scenario: > > The SCA Assembly TC requests upload of CSD08 of the Assembly > specification. This includes a normative reference to CSD04 of the SCA > Web Service Binding owned by the SCA Bindings TC (in fact this spec > includes normative references to around 10 specs from other SCA TCs). > The CSD upload is successful and 15 day public review goes ahead. > > The SCA Bindings TC then requests upload of CSD05 of the Web Service > Binding specification. This includes changes which require public > review, but no incompatible changes related with the SCA Assembly > specification. The Web Service Binding specification includes a > normative reference to the SCA Assembly Specification CSD08. The CSD > upload is successful and 15 day public review goes ahead. > > Now the SCA Assembly and SCA Bindings TCs want to take their > specifications to CS level (I'm assuming here that the TCs coordinate > the CS submissions of a number of specifications) However the Assembly > specification includes a reference to Web Service Binding CSD04 which is > not the most recent version. > > The question then is, would the SCA Assembly TC have to have another > public review of the Assembly specification (and therefore a new CSD, > and therefore making the Web Service binding spec refer to an older > version of Assembly), or would it be acceptable for the CS motion to > include a designated cross reference which updates the Web Service > Binding reference from CSD04 directly to the Web Service Binding CS > (skipping CSD05)? > > There has been debate in the SCA Bindings TC around the CSD/PR requests > we have in the pipeline at the moment. We have Web Service binding and > JMS Binding specs in the CSD/PR pipeline which refer to the SCA Assembly > specification (CSD8), however that is also in the pipeline ahead of > them, and so when they get to be processed the reference to Assembly > will already be out of date, (and also the references from Assembly spec > to those specs will be out of date). However I can't see any way to > indicate in the upload requests that these normative references should > be updated other than informal comments. The TC is not keen on the idea > of having all these CSD requests processed as a single unit of work, > assuming this will inevitably introduce additional delays. This also > would not solve the issue of the circular references between the specs. > The answer to the scenario above might render this moot if we can update > all the normative references between SCA specification documents as part > of the CS process, and not worry about the versions mentioned in the > current CSDs being to the most recent. > > Thanks, Simon > > Simon Holdsworth > > > > From: Chet Ensign <chet.ensign@oasis-open.org> > To: Simon Holdsworth/UK/IBM@IBMGB > Cc: Robin Cover <robin@oasis-open.org>, Paul Knight > <paul.knight@oasis-open.org>, OASIS TAB <tab@lists.oasis-open.org> > Date: 29/07/2011 00:18 > Subject: Re: [members] Please follow these steps to avoid problems with > your requests for TC Admin support > ------------------------------------------------------------------------ > > > > Hi Simon, > > The TAB discussed this issue today. This is a problem in every > standards organization where multiple parties are moving work forward > on different schedules and we are trying to come up with proposals to > the Board Process Committee. In regard to your specific questions... > > On Mon, Jul 25, 2011 at 8:19 AM, Simon Holdsworth > <simon_holdsworth@uk.ibm.com> wrote: > > So really the question is how we keep these cross-references up to date, > > without requiring a new CSD and PR of all the specs every time one of the > > related specs is updated > One option is to use the "Latest Version" link from the spec's front > page in your cross-reference. This will resolve to the latest of the > CSD's for the specific specification rather than to the published > version at the time you approved your CSD. Your risk there of course > is that the most recent CSD may have changes in it that you haven't > accounted for in your spec - that is a risk you would need to weigh > yourselves. > > - and whether its OK for the TC to request that a > > normative reference within a spec is updated as part of the CSD upload > > request. > The TAB discussed modifying Section 2.19, Designated Cross References > to apply to CSD's as well as CS's. That is the mechanism you would > use. I will be sending the Chairs an explanation and update on that in > the near future. Under that step, you would make a special motion as > part of your approval to publish as a CSD. Understand that one result > of that is that publication of your CSD is put on hold until the > referenced spec is completed and published. > > Does this give you the information you need? If you would like, I > would be happy to get on the phone and talk about this further. > > Best, > > /chet > > > > > [1] http://tools.oasis-open.org/issues/browse/TCADMIN-578 > > > > Thanks, Simon > > > > Simon Holdsworth > > STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC > Chair, > > AT&T and Boeing Lab Advocate > > MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK > > Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898 > > Internet - Simon_Holdsworth@uk.ibm.com > > > > > > > > From: Chet Ensign <chet.ensign@oasis-open.org> > > To: chairs@lists.oasis-open.org, members@lists.oasis-open.org > > Cc: Staff <staff@lists.oasis-open.org>, OASIS Board Process Committee > > <board-process@lists.oasis-open.org>, OASIS TAB > <tab@lists.oasis-open.org>, > > Laurent Liscia <laurent.liscia@oasis-open.org>, Robin Cover > > <robin@oasis-open.org>, Paul Knight <paul.knight@oasis-open.org> > > Date: 23/07/2011 21:11 > > Subject: [members] Please follow these steps to avoid problems with > > your requests for TC Admin support > > ________________________________ > > > > > > All, > > > > We have recently encountered some problems with TC requests to create > > committee drafts and submit them to public review. Specifically: > > > > - Meeting minutes or ballots have not clearly identified the source > > files for the Working Draft being voted on or failed to clearly record > > the vote > > - The Working Draft submitted to TC Administration for processing has > > been different from the one the TC approved > > - The TC has approved unfinished Working Drafts or requested that TC > > Administration make changes to the content of the Working Draft after > > submission > > > > In some cases, we have had to reject requests as submitted and ask the > > TC to address these problems. > > > > Please, in order to avoid added delays in servicing your requests, > > ensure that you adhere to the following requirements as published in > > the TC Process and related documents [1] when you submit a request: > > > > 1. Ensure that the motions you vote on to approve Working Drafts as > > Committee Specification/Note Drafts include the URI to the zip file or > > unique archive containing all component materials that are to be > > approved by the TC and that the vote itself is clearly recorded in the > > meeting minutes. (Note that the archive must include editable source > > format files and all component files that are part of the Working > > Draft.) > > > > For example, a motion in your minutes such as the following will meet > > this requirement: > > > > "Motion: Shall the OASIS Mumble-Mumble TC approve Mumble > > Profile Version 1.0 Working Draft 07 and its associated artifacts > > packaged together in > > http://www.oasis-open.org/committees/download.php/39296/Mumble07.zip > > as OASIS Mumble Profile v1.0 > > Committee Specification Draft 01 and direct the Chair to > > submit this Working Draft to TC Administrator for creation and upload > > as > > soon as practicable. > > > > Motion made by Bob Smith. Seconded by Shirley Jones. 7 votes > > in favor, 1 abstention, no votes opposed. Motion passes." > > > > 2. Ensure that the TC Administration request (made via > > http://www.oasis-open.org/resources/tc-admin-requests) includes the > > link to the ballot or to the minutes where the motion and approval > > were made and the same URI to the zip file or archive approved. > > > > We have encountered requests where the minutes provided actually > > mentioned earlier meetings where the draft was approved and we've had > > to request that the reference be corrected. We have also received > > requests where the Working Draft URI provided was something different > > from what the TC voted to approve and we've had to reject those > > requests. > > > > 3. Ensure that your Working Draft is complete and ready to go. > > > > We cannot accept as valid a submission approved by the TC "…contingent > > on Chet fixing those links he's been promising to fix for weeks." Get > > it all done - then vote to approve it. > > > > 4. And should you find that you need to make some changes or > > corrections after submitting a Working Draft to TC Administration, > > first, get in touch with us so that we can coordinate next steps with > > you and second, create a new, complete, numerically incremented > > Working Draft and hold another TC vote to approve it. Per TC Process > > rules, we cannot accept requests to piece-meal replace parts of your > > submitted Working Draft with replacements. > > > > If we have not yet assigned anyone to your request and started work on > > the draft, we can update the existing request with the new Working > > Draft. If we have assigned someone to the ticket and work has begun, > > we reserve the right require you to enter a new request. > > > > I realize that this may look like a lot of bureaucracy to some, > > particularly item 4. So I want to stress that the TC Process rules are > > in place to ensure that the integrity and quality of your work is > > unassailable. We ask you to take the steps above in order to guarantee > > to the world that your Committee Specifications, Committee Notes or > > OASIS Standards are the unalloyed work of your TC and that their > > quality and integrity cannot be called into question. The work is your > > accomplishment; we want to make sure that everyone respects it. > > > > Please let me know if you have any questions. > > > > Best regards, > > > > /chet > > ---------------- > > Chet Ensign > > Director of Standards Development and TC Administration > > OASIS: Advancing open standards for the information society > > http://www.oasis-open.org <http://www.oasis-open.org/> > > > > Primary: +1 973-378-3472 > > Mobile: +1 201-341-1393 > > > > Follow OASIS on: > > LinkedIn: http://linkd.in/OASISopen > > Twitter: http://twitter.com/OASISopen > > Facebook: http://facebook.com/oasis.open > > > > --- > > > > [1] References > > > > *** OASIS TC Process *** > > > > 2.18 Work Product Quality > > > http://www.oasis-open.org/policies-guidelines/tc-process-2010-07-28#specQuality > > File Formats > > > http://www.oasis-open.org/policies-guidelines/tc-process-2010-07-28#quality-fileFormats > > Multi-Part Work Products > > > http://www.oasis-open.org/policies-guidelines/tc-process-2010-07-28#quality-multiPart > > > > *** TC Handbook *** > > > > Approval of a Committee Specification Draft > > > http://docs.oasis-open.org/TChandbook/Reference/CommitteeSpecDrafts.html#wd > > > > --------------------------------------------------------------------- > > > > This email list is used solely by OASIS for official consortium > > communications. > > > > Opt-out requests may be sent to member-services@oasis-open.org, > however, all > > members are strongly encouraged to maintain a subscription to this list. > > > > > > > > > > > > ________________________________ > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > > > > > > > > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org <http://www.oasis-open.org/> > > Primary: +1 973-378-3472 > Mobile: +1 201-341-1393 > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open > > > > > ------------------------------------------------------------------------ > > / > / > > /Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/ > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]