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 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]