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
<> 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
>> < <mailto:>> 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
>> < <mailto:>> 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:>]
>> 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
>> < <mailto:>> 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:.__com
>> <mailto:>]
>> 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:
>>
>> <mailto:>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From:
>>
>> "Patil, Sanjay" <
>> <mailto:>>
>>
>> To:
>>
>> Anish Karmarkar <
>> <mailto:>>, OASIS Liaison
>> <-__open.org
>> <mailto:>>
>>
>> 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:>]
>> 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
>> <mailto:>
>> 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:> - 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
