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


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]