[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
Thanks Jeff - makes sense. I will draft the problem statement for us to go over in the TAB first. On Tue, Aug 9, 2011 at 11:35 AM, Jeff Mischkinsky <JEFF.MISCHKINSKY@oracle.com> wrote: > 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 > > > > > > > > > > -- /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]