Re: [opencsa-ms] SCA TC Liaison issues

[Jeff Mischkinsky <jeff.mischkinsky@oracle.com>]

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:  mike_edwards@uk.ibm.com
>
>
> Anish Karmarkar <Anish.Karmarkar@oracle.com>
> 24/09/2007 18:30
>
> To
> opencsa-ms@lists.oasis-open.org
> cc
> "Patil, Sanjay" <sanjay.patil@sap.com>, Mike Edwards/UK/IBM@IBMGB,  
> Martin Chapman <martin.chapman@oracle.com>, Ashok Malhotra  
> <ashok.malhotra@oracle.com>, David Booz <booz@us.ibm.com>, Michael  
> Rowley <mrowley@bea.com>, "Blohm, Henning" <henning.blohm@sap.com>,  
> Bryan Aupperle <aupperle@us.ibm.com>, 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			          		jeff.mischkinsky@oracle.com
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