Thanks Ron/Jeff, your point is taken. Nevertheless I think that we
should target for producing backward compatible specifications as much
as possible, and calling the OASIS versions as 1.1 would be a good
starting point.
-- Sanjay
> -----Original Message-----
> From: Jeff Mischkinsky [mailto:]
> Sent: Wednesday, Sep 26, 2007 0:06 AM
> To: Ron Ten-Hove
> Cc: Patil, Sanjay; Mike Edwards; Anish Karmarkar; Ashok
> Malhotra; Bryan Aupperle; David Booz; Blohm, Henning; Martin
> Chapman; Michael Rowley; ;
> Simon Holdsworth
> Subject: Re: [opencsa-ms] SCA TC Liaison issues
>
>
> On Sep 25, 2007, at 11:02 AM, Ron Ten-Hove wrote:
>
> > Sanjay,
> >
> > I believe Jeff was referring to the WS-BPEL TC, not the
> SCA BPEL
> > WG. As a witness to that TC's debates, I can attest that his
> > description is accurate.
>
> that's correct.
> -jeff
> >
> > --Ron
> >
> > Patil, Sanjay wrote:
> >> Some clarification: AFAICT, The SCA BPEL TC did not have
> any lengthy
> >> debate about picking 1.1 Vs 2.0 numbering for the OASIS revision.
> >> Rather, the issue about version numbering was noted and quickly
> >> tabled
> >> with the assumption that the version numbering issue applies to
> >> all the
> >> Open CSA TCs and should be resolved elsewhere in a
> consistent manner.
> >>
> >> Personally, I prefer that we start with calling the OASIS
> >> revisions of
> >> the SCA specifications as version 1.1 and possibly bump up the
> >> version
> >> number to 2.0 before finalization in case we end up making backward
> >> incompatible changes.
> >>
> >> -- Sanjay
> >>
> >>
> >>> -----Original Message-----
> >>> From: Jeff Mischkinsky
> [mailto:] Sent:
> >>> Monday, Sep 24, 2007 20:37 PM
> >>> To: Mike Edwards
> >>> Cc: Anish Karmarkar; Ashok Malhotra; Bryan Aupperle; David Booz;
> >>> Blohm, Henning; Martin Chapman; Michael Rowley; opencsa-
> >>> ; Patil, Sanjay; Simon Holdsworth
> >>> Subject: Re: [opencsa-ms] SCA TC Liaison issues
> >>>
> >>>
> >>> On Sep 24, 2007, at 2:22 PM, Mike Edwards wrote:
> >>>
> >>>
> >>>> Anish,
> >>>>
> >>>> Thanks for bringing these items forward.
> >>>>
> >>>> I have a suggestion of how to deal with these items and
> similar
> >>>> items in the short run. I suspect
> >>>> that what I suggest will form part of the long run
> process anyway.
> >>>>
> >>>> These items should be placed onto the Agenda of upcoming
> >>>> meetings of each TC by the chair(s)
> >>>> of those TCs, with the aim of getting each TC to make a
> >>>> decision. In order to do this, each item must
> >>>> be couched in terms of a definitive recommendation that can be
> >>>> adopted.
> >>>>
> >>>> Issue 2 below is in the right form.
> >>>>
> >>>> Issue 1 below is more of a discussion. Here is a proposal:
> >>>>
> >>>> -------
> >>>>
> >>>> Issue 1: What should be the version of the SCA specs?
> >>>>
> >>>> To avoid confusion, all the initial specifications produced by
> >>>> the SCA TCs belonging to the Open CSA MS
> >>>> will be given the label "Version 1.1".
> >>>>
> >>> ok, let the naming debate begin. :-)
> >>>
> >>> We (ORCL) discussed this issue internally and came to the
> >>> tentative conclusion that we should probably call these 2.0,
> >>> unless it does in fact turn out that ALL of the specs
> will be be
> >>> backward compatible with the 1.0 versions. Obviously we
> have our
> >>> doubts that will be the ultimate outcome.
> >>> FWIW, it was noted that the BPEL TC went through a similar
> >>> lengthy debate and finally settled on 2.0.
> >>>
> >>> That said, I suspect that it is probably premature to decide on
> >>> a name. We should wait until we are much closer to
> "release" and
> >>> have a better understanding of the diffs that are adopted. So
> >>> how about we pick just pick a code name (its more fun to have a
> >>> code name contest than to argue about 1.1 vs. 2.0 :-)
> >>> The winner gets a free copy.
> >>>
> >>> cheers,
> >>> jeff
> >>>
> >>>
> >>>
> >>>> This will enable all the specifications to be clearly related
> >>>> to each other and also to be distinguished from
> >>>> the Version 1.0 SCA specifications published by the Open SOA
> >>>> collaboration in March 2007.
> >>>>
> >>>> -------
> >>>>
> >>>> Now all that is required is to get each TC to adopt the
> >>>> resolution for each of these issues.
> >>>>
> >>>> The real liaison will begin if and when TCs disagree about the
> >>>> resolution ;-)
> >>>>
> >>>>
> >>>> Yours, Mike.
> >>>>
> >>>> Strategist - Emerging Technologies, SCA & SDO.
> >>>> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN,
> >>> Great Britain.
> >>>
> >>>> Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
> >>>> Email:
> >>>>
> >>>>
> >>>> Anish Karmarkar <>
> >>>> 24/09/2007 18:30
> >>>>
> >>>> To
> >>>>
> >>>> cc
> >>>> "Patil, Sanjay" <>, Mike Edwards/UK/
> >>>> IBM@IBMGB, Martin Chapman <>, Ashok
> >>>> Malhotra <>, David Booz
> >>>> <>, Michael Rowley <>, "Blohm,
> >>>> Henning"
> >>> <>,
> >>>> Bryan Aupperle <>, Simon
> Holdsworth/UK/IBM@IBMGB
> >>>> Subject
> >>>> [opencsa-ms] SCA TC Liaison issues
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Open CSA SC,
> >>>>
> >>>> The SCA BPEL TC has two issues, which were discussed
> during the
> >>>> recently
> >>>> concluded F2F, that require coordination across all SCA TCs.
> >>>> Since there
> >>>> is no official liaison mechanism set up, on behalf of SCA
> >>> BPEL TC I'm
> >>>
> >>>> bringing these issues to the attention of the Open CSA SC. I
> >>>> would like
> >>>> to request the SC to coordinate this across all the SCA TCs.
> >>>>
> >>>> Issue 1: What should be the version of the SCA specs?
> >>>>
> >>>> Should the version of the SCA specs be 2.0 or 1.x? Or
> >>> something else?
> >>>
> >>>> It is certainly possible to have the assembly specification
> >>> be version
> >>>
> >>>> 2.0 and BPEL C&I specification version that depends on
> >>> assembly 2.0 be
> >>>
> >>>> 1.5, for example. But such version numbers will be very
> >>>> confusing. Given
> >>>> that the TCs are affiliated with the Open CSA MS, a
> better approach
> >>>> would be to have the same version number for all the
> initial output
> >>>> specifications of the various SCA TC. If not, at the very
> >>> least, have
> >>>
> >>>> the number before the "." be the same. This will require
> >>> coordination
> >>>
> >>>> and agreement across all the TCs.
> >>>>
> >>>> Issue 2: Use of RFC 2119 keywords in the spec
> >>>>
> >>>> In aligning the spec with the OASIS template and accepting the
> >>>> OASIS TAB
> >>>> recommendations, the SCA BPEL TC decided to use the RFC
> >>> 2119 keywords
> >>>
> >>>> along with the following restriction:
> >>>> a) All RFC 2119 keywords will be of the uppercase form (for
> >>>> example, RFC
> >>>> 2119 keywords MUST be capitalized)
> >>>> b) use of lowercase 2119 keywords will not be used in
> the spec.
> >>>> When the
> >>>> use of 2119 keyword is needed, without having the
> implications wrt
> >>>> conformance, a suitable synonym will be found.
> >>>> c) RFC 2119 defines keywords that are synonyms of each other. For
> >>>> example 'SHALL' and 'MUST' mean the same thing. The TC
> >>> decided to not
> >>>
> >>>> use multiple forms to mean the same. Therefore the TC
> decided to
> >>>> use
> >>>> 'MUST' instead of 'SHALL' and 'MUST NOT' instead of
> 'SHALL NOT'
> >>>> through
> >>>> out the spec.
> >>>> Please note that the use of RFC 2119 keywords affect conformance.
> >>>> Consistency across the SCA spec with respect to conformance
> >>> and the
> >>>> use
> >>>> of normative conformance lanaguage is highly desirable.
> >>>>
> >>>> Please let me know if you have any questions.
> >>>>
> >>>> Thanks and regards.
> >>>>
> >>>> -Anish Karmarkar
> >>>> SCA BPEL TC co-chair on behalf of SCA BPEL TC
> >>>> --
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>> --
> >>> Jeff Mischkinsky
> >>>
> >>> Director, Oracle Fusion Middleware and Web Services
> Standards +1
> >>> (650) 506-1975
> >>> Consulting Member Technical Staff
> >>> 500 Oracle Parkway, M/ S 4OP9
> >>> Oracle
> >>> Redwood Shores, CA 94065
> >>>
> >>>
> >>>
> >>>
> >
> > --
> > Sun's Open ESB Community (http://open-esb.org)
> >
>
> --
> Jeff Mischkinsky
>
> Director, Oracle Fusion Middleware and Web Services Standards +1(650)
> 506-1975
> Consulting Member Technical Staff
> 500 Oracle Parkway, M/
> S 4OP9
> Oracle
> Redwood Shores, CA 94065
>
>
>
