[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tab] Re: [opencsa-liaison] Reference dependencies in various SCA specs
Jeff et al - I'll draft this up into a note to send the the BPC mailing list. This is an opportunity for people to comment on the problem statement and make sure I have correctly captured and characterized both the problem and the proposed solution. The problem being raised (and thank you Sanjay and Mike for bumping it up a notch) is a narrow one: - A given TC has a Working Draft (WD) approved and submitted for publication as a Committee Specification Draft (CSD). This WD contains references to other approved WD’s that will, at some point in the near future, be approved and published as CSD's. - The TC wants to proceed with publication of their CSD with the references to the approved WD's and have TC Administration update the references in the published CSD at a later date from approved WD to CSD when the referenced specifications are themselves published. - In addition, they want this done without triggering a 15 day public review of the updated CSD. - This situation would be addressed by TC Process section 2.19, Designated Cross Reference Changes and by section 2.18, Work Product Quality item (6) Allowed Changes *if* section 2.19 applied at the CSD stage of a specification. Right now, 2.19 only applies to approvals for Committee Specification and above. The solution being proposed is to allow section 2.19 to apply to CSD approvals as well as CS approvals. (Note for the TC's to consider: as currently constructed, application of section 2.19 will result in publication of the referencing CSD being held up until all the cross-referenced specifications are published. To proceed with immediate publishing of the CSD and subsequent updates to the references requires additional changes to section 2.19.) In addition, we need to answer a second question this raises: what cross references are specifically meant in 2.19: 1. The references in the Related Work section of the cover pages to the specification only? 2. That plus the cross references in the Normative / Non-Normative References section of the specification body? (Meaning that TC Administration would be responsible for making changes with the content produced by the TC.) 3. *Any* cross reference anywhere in the narrative specification document? 4. *Any* cross reference anywhere in *any* component of the complete specification? I ask because I have had other TC's argue that it means item #4. Please provide any comments on this. Jeff, I can send the above to board-process-committee@ if you'd like. Best, /chet On Tue, Aug 9, 2011 at 9:57 AM, Martin Chapman <MARTIN.CHAPMAN@oracle.com> wrote: > 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 >> > -- /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]