[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tab] Re: [opencsa-liaison] Reference dependencies in various SCAspecs
We removed C*Ds from the DCR section because we argued that a TC could always produce another draft. However, what we didn't do was to examine the inter-dependency of this rationale with the 15 public review for any change (aside from 2.18(6) changes), and we are seeing some of that interplay here. I think if a TC can show that a normative reference has not been materially changed i.e. only a status change has been made - reflected by the changes permissible in section 2.18(6)- they (or TC Admin) should be able to update the reference to that changed version. It should be easy to track if only 2.18(6) changes have been made. Martin. > -----Original Message----- > From: Jeff Mischkinsky > Sent: 09 August 2011 03:01 > To: Chet Ensign > Cc: Patil, Sanjay; Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; > Paul Knight; Robin Cover > Subject: [tab] Re: [opencsa-liaison] Reference dependencies in various SCA > specs > > 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> > > 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] > > 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> > > 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] > > 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 > > > > > > > > Mobile: > > > > +44-7802-467431 (274097) > > > > > > > > e-mail: > > > > mike_edwards@uk.ibm.com > > > > > > > > > > > > > > > > > > > > > > From: > > > > "Patil, Sanjay" <sanjay.patil@sap.com> > > > > To: > > > > Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <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] > > 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 > > [2] 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 > > > > > > > > > > > > > > > > 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 > > Mobile: +1 201-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 > > Mobile: +1 201-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 > Sr. Director, Oracle Fusion Middleware +1(650)506- > 1975 > and Web Services Standards 500 Oracle > Parkway, M/S 2OP9 > Oracle Redwood Shores, CA 94065 > > > > > > > > > > > --------------------------------------------------------------------- > 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]