[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs
Anish, can we spell out those solutions? - Allow 2.19 to apply at the CSD level - Have TC Admin provide the future URI's for the referenced CSD's to the editors for use when they approve their WD for CSD - ? I'm not sure I saw the third ... Also, another possible solution: Where a published CSD## already exists and the WD will result in publication of CSD##+1, use the "Latest Version" URL in the cross-reference. That will always resolve to the latest CSD for the referenced specification. I'll add the proposals to my write up... /chet On Tue, Aug 9, 2011 at 11:09 AM, Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote: > Paul, > > Thanks for correcting that. Should have been more precise in my email. > But in the context of the current discussion, the SCA TCs are looking to go > to CS soon. The problem they face is that to go to CS, the current rules > will require infinite number of CSDs and PRs because of the > cross-dependencies, unless we find a way to break the cycle. I have proposed > three different ways to move this forward. Perhaps there are more. > > -Anish > -- > > On 8/8/2011 7:37 PM, Paul Knight wrote: >> >> Hi all, >> >> A point which I think may be misquoted and/or misunderstood: >> >> "the requirement of new PRs for any change" >> >> mentioned by both Jeff and Anish is not a "requirement". >> >> A PR is needed ONLY if the immediately following step is a vote for >> making the Work Product a Committee Specification (or Note). TCs should >> not believe that they have to do a new PR every time they produce a CSD. >> >> In fact, avoiding doing the PR until all the cross-referenced Work >> Products are at stable CSD states may provide a known and fairly stable >> target URI (i.e, the upcoming PR version), which may allow some >> efficiencies for everyone. >> >> However, in any case, Chet is setting up a process to get concerns and >> approaches clarified. >> >> Best regards, >> Paul >> >> On Mon, Aug 8, 2011 at 10:01 PM, Jeff Mischkinsky >> <jeff.mischkinsky@oracle.com <mailto:jeff.mischkinsky@oracle.com>> wrote: >> >> we can also allocate some time in Process Committee if that would be >> desireable/easier. >> >> FWIW I think the problem is that the SCA TCs are not really >> completely independent of each other. (I think of them as "almost >> separable".) When we were first developing SCA we discussed whether >> we should have one big TC or break things up to make development >> more manageable realizing that the trade-off was that we would have >> mutual dependencies. >> >> That said i'm not sure the real issue is independent TCs. The mutual >> dependencies would exist even if there was one TC. Having multiple >> TCs makes it more complicated because its harder to coordinate >> simultaneous votes on mutually dependent specs across TCs. I'm >> trying to remember why we don't allow DCR's for CSD's. I *think* it >> might be because we thought that since these were "only drafts", it >> was ok if there were some inconsistencies/bugs and not worth the >> effort to allow DCR's. >> >> The suggestion to allow TC's to decide if a change is not >> "substantive enough" is that we were never able to agree on a >> definition of what "enough" meant and TCs will almost always declare >> a change to be non-substantive, regardless. >> >> Actually we already have that issue on the Process Committee's >> agenda as part of figuring out if the requirement of new PRs for any >> change is creating too many PRs. >> >> cheers, >> jeff >> >> >> On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: >> >> Mike, Sanjay - Actually, before launching on a broad chat, I >> think it would make more sense for us to talk and frame the >> problem to be solved so that conversation can be productive. Can >> I set up a call with both of you, maybe for Wednesday or >> Thursday? That will give me some time to draft a first pass at a >> problem statement that we can use to set up productive >> discussion with others. >> >> /chet >> >> On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay >> <sanjay.patil@sap.com <mailto:sanjay.patil@sap.com>> wrote: >> I think it makes a lot of sense to have a conference call to >> jointly define the problem and brainstorm the potentially >> solutions. However, scheduling a call with the many interested >> parties from the various time zones might become tricky. One >> option may be to check with the SCA Assembly TC chairs if they >> would be ok to allocate some of their weekly meeting time (Tue 8 >> AM PST) for this topic (assuming that Chet and other concerned >> OASIS staff / TAB members can make it). I believe that most of >> the SCA TC chairs are also members of the SCA Assembly TC and >> moreover the SCA TCs typically look forward to the SCA Assembly >> TC to resolve such cross-cutting issues and set the precedent. >> Mike/Martin, any thoughts in this regard? >> >> >> >> Sanjay >> >> >> >> From: Chet Ensign [mailto:chet.ensign@oasis-__open.org >> <mailto:chet.ensign@oasis-open.org>] >> Sent: Monday, August 08, 2011 3:20 PM >> To: Patil, Sanjay >> Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; >> Paul Knight; Robin Cover >> Subject: Re: [opencsa-liaison] Reference dependencies in various >> SCA specs >> >> >> >> Sanjay, Mike et al - We started a discussion on this subject at >> the TAB F2F and it is on our agenda. If you all would like, I >> would like to schedule a conference call so that we can discuss >> together and ... >> >> >> >> - Jointly define the problem(s) - typically the most difficult >> part of any of these conversations <grin> >> >> - Discuss what limitations of the current process / rules >> contribute to the problem(s) >> >> - Brainstorm possible modifications that could resolve the >> problem(s) >> >> >> >> Is that something you all are interested in doing? >> >> Best, >> >> >> >> /chet >> >> On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay >> <sanjay.patil@sap.com <mailto:sanjay.patil@sap.com>> wrote: >> >> >> >> Do other TC chairs have any further viewpoints on this topic? >> >> >> >> Since the resolution of this issue may involve changes to >> procedures involving the TC Admin (and potentially the TC >> process!), we need to decide how to take this issue forward. At >> the minimum, I think we should inform the TC Admin about our >> opinions and start the discussion. I am taking the liberty to >> copy Chet Ensign on this email thread to set the ball rolling. >> >> >> >> Best wishes, >> >> Sanjay >> >> >> >> From: Mike Edwards [mailto:mike_edwards@uk.ibm.__com >> <mailto:mike_edwards@uk.ibm.com>] >> Sent: Wednesday, August 03, 2011 1:33 AM >> To: Patil, Sanjay >> Cc: Anish Karmarkar; OASIS Liaison >> Subject: RE: [opencsa-liaison] Reference dependencies in various >> SCA specs >> >> >> >> >> Sanjay, >> >> I agree with your views. >> >> In the latest round of changes, for example, I think that >> Assembly is not affected by the changes to the >> other specifications (Policy, WS-Binding, Java...), even though >> those changes are normative. >> >> As a result, in my opinion, updating the Assembly spec to >> reference the latest CSDs of the other specs >> is a purely editorial process. >> >> Each TC may need to take a vote that agrees this for any >> particular spec, but once that vote has >> taken place, the update should be purely mechanical. No new >> public reviews are required. >> >> >> Yours, Mike >> >> Dr Mike Edwards >> >> Mail Point 137, Hursley Park >> >> <image001.gif> >> >> >> STSM >> >> Winchester, Hants SO21 2JN >> >> SCA, Cloud Computing & Services Standards >> >> United Kingdom >> >> Co-Chair OASIS SCA Assembly TC >> >> >> >> Chair UK ISO SC38 mirror committee (Cloud & SOA) >> >> >> >> IBM Software Group >> >> >> >> Phone: >> >> +44-1962 818014 <tel:%2B44-1962%20818014> >> >> >> >> Mobile: >> >> +44-7802-467431 <tel:%2B44-7802-467431> (274097) >> >> >> >> e-mail: >> >> mike_edwards@uk.ibm.com <mailto:mike_edwards@uk.ibm.com> >> >> >> >> >> >> >> >> >> >> >> From: >> >> "Patil, Sanjay" <sanjay.patil@sap.com >> <mailto:sanjay.patil@sap.com>> >> >> To: >> >> Anish Karmarkar <Anish.Karmarkar@oracle.com >> <mailto:Anish.Karmarkar@oracle.com>>, OASIS Liaison >> <opencsa-liaison@lists.oasis-__open.org >> <mailto:opencsa-liaison@lists.oasis-open.org>> >> >> Date: >> >> 02/08/2011 17:56 >> >> Subject: >> >> RE: [opencsa-liaison] Reference dependencies in various SCA specs >> >> >> >> >> >> >> >> I think the option 3 provides the required solution while >> retaining the independence for the TCs to decide and follow >> their own schedule. During CSD publication and PR, specs can >> make references to the existing source material as of that time. >> Later, it should be allowed to update the references without >> having to go for another round of PR. I think it is reasonable >> to trust the TCs in making a determination about whether a >> change in a reference is significant enough to require another >> round of PR or not. >> >> Sanjay >> >> >> -----Original Message----- >> From: Anish Karmarkar [mailto:Anish.Karmarkar@__oracle.com >> <mailto:Anish.Karmarkar@oracle.com>] >> Sent: Tuesday, August 02, 2011 9:22 AM >> To: OASIS Liaison >> Subject: [opencsa-liaison] Reference dependencies in various SCA >> specs >> >> As we all know, specs in all the SCA TCs have dependencies on each >> other. For example, Assembly has a normative reference to Policy >> and >> WS-Binding. To conform to Assembly one has to conform to Policy and >> WS-Binding. Policy in turn depends on Assembly. WS-Binding >> depends on >> Assembly/Policy. The dependency graph is cyclic. >> >> A similar problem exists in SCA-J TC but without any cycles [1]. >> >> OASIS TC process solves this problem of cyclic references by using >> designated cross references [2]. Unfortunately, CSDs cannot use >> this >> mechanism as the process explicitly excludes it. So, two specs A >> and B >> that depend on each other, will be in an infinite loop wrt updating >> their normative references. Further compounding the problem (but >> is an >> independent issue) is the fact that the new process requires at >> least >> 15-days PR for any change (except the changes on the front >> page). So any >> time spec A or B is updated to update its normative reference it >> has to >> be PRed. >> >> I see three possible solutions to this: >> 1) Fix the process to allow DCRs for CSDs (this is the only long >> term >> solution, I think). >> 2) Use the solution in [1] where spec A instead of using WDXX >> reference >> of B, uses the CSDYY reference of B. Where CSDYY is the what >> will happen >> to WDXX when the TC Admin processes the request for WDXX to be >> published >> as CSD. This means that the CSDs of A and B should be >> coordinated to go >> in the TC Admin queue around the same time. >> 3) Get TC admin to update normative references when there is no >> material >> change. For example, in (2) above, WDXX and CSDYY are going to be >> identical specs except for the front page. If spec A references >> WDXX, >> the TC admin should be able to update that reference to CSDYY. A >> similar >> update would have to be done to spec B. >> >> -Anish >> -- >> >> [1] >> http://lists.oasis-open.org/__archives/sca-j/201107/__msg00028.html >> <http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html> >> [2] >> >> http://www.oasis-open.org/__policies-guidelines/tc-__process#crossRefs >> >> <http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs> >> >> >> ------------------------------__------------------------------__--------- >> To unsubscribe from this mail list, you must leave the OASIS TC >> that >> generates this mail. Follow this link to all your TCs in OASIS at: >> >> https://www.oasis-open.org/__apps/org/workgroup/portal/my___workgroups.php >> >> <https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php> >> >> >> >> >> >> >> >> 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 >> >> Primary: +1 973-378-3472 <tel:%2B1%20973-378-3472> >> Mobile: +1 201-341-1393 <tel:%2B1%20201-341-1393> >> >> Follow OASIS on: >> LinkedIn: http://linkd.in/OASISopen >> Twitter: http://twitter.com/OASISopen >> Facebook: http://facebook.com/oasis.open >> >> >> >> >> -- >> >> /chet >> ---------------- >> Chet Ensign >> Director of Standards Development and TC Administration >> OASIS: Advancing open standards for the information society >> http://www.oasis-open.org >> >> Primary: +1 973-378-3472 <tel:%2B1%20973-378-3472> >> Mobile: +1 201-341-1393 <tel:%2B1%20201-341-1393> >> >> Follow OASIS on: >> LinkedIn: http://linkd.in/OASISopen >> Twitter: http://twitter.com/OASISopen >> Facebook: http://facebook.com/oasis.open >> >> >> -- >> Jeff Mischkinsky jeff.mischkinsky@oracle.com >> <mailto:jeff.mischkinsky@oracle.com> >> Sr. Director, Oracle Fusion Middleware +1(650)506-1975 >> <tel:%2B1%28650%29506-1975> >> and Web Services Standards 500 >> Oracle Parkway, M/S 2OP9 >> Oracle >> Redwood Shores, CA 94065 >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> Paul Knight <mailto:paul.knight@oasis-open.org> - Tel: +1 781-861-1013 >> OASIS <http://www.oasis-open.org/> - Advancing open standards for the >> information society >> Document Process Analyst >> <http://www.oasis-open.org/people/staff/paul-knight> >> >> > -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]