OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

opencsa-liaison message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs


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
<Anish.Karmarkar@oracle.com> 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
>> <jeff.mischkinsky@oracle.com <mailto:jeff.mischkinsky@oracle.com>> 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
>> � � � �<sanjay.patil@sap.com <mailto: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
>> � � � �<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 <mailto: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
>> � � � �<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 <tel:%2B44-1962%20818014>
>>
>>
>>
>> � � � �Mobile:
>>
>> � � � �+44-7802-467431 <tel:%2B44-7802-467431> (274097)
>>
>>
>>
>> � � � �e-mail:
>>
>> � � � �mike_edwards@uk.ibm.com <mailto:mike_edwards@uk.ibm.com>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> � � � �From:
>>
>> � � � �"Patil, Sanjay" <sanjay.patil@sap.com
>> <mailto:sanjay.patil@sap.com>>
>>
>> � � � �To:
>>
>> � � � �Anish Karmarkar <Anish.Karmarkar@oracle.com
>> � � � �<mailto:Anish.Karmarkar@oracle.com>>, OASIS Liaison
>> � � � �<opencsa-liaison@lists.oasis-__open.org
>> � � � �<mailto: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
>> � � � �<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
>> � � � �<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 jeff.mischkinsky@oracle.com
>> � �<mailto:jeff.mischkinsky@oracle.com>
>> � �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:paul.knight@oasis-open.org> �- 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]