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: [tab] Re: [opencsa-liaison] Reference dependencies in various SCAspecs


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
> 


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