[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
hi chet, It also seems to me, as you point out, that this issue has much broader applicability than just the SCA TCs, so i think we should formally raise and address this issue by the Process Committee. That said, getting input and discussion from a wider group is a good thing, and I don't mean to try to stifle that. We have enough on the process comm agenda for the next several weeks, so developing a well formed proposal out of band is probably also a good thing. Also, as martin noted, the TAB already has this on its agenda, so why don't we let it be the focus for the discussion for a while - with an occasional update to Process. I do note that cross posting across multiple oasis lists, for which different people have read/write permission could prove to be awkward -- and process is probably the most limited list which is an added complication. cheers, jeff On Aug 09, 2011, at 8:21 AM, Chet Ensign wrote: > 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 -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]