RE: [opencsa-ms] SCA TC Liaison issues

["Mary McRae" <mary.mcrae@oasis-open.org>]

Hi everyone,

  I just wanted to chime in, regarding Issue 2, that the while the document
produced by the TAB has been approved by the TAB and forwarded to staff, it
has not been published as guidelines or recommendations. There is some
confusion about what keywords should or should not be used, and a
recently-prepared chart makes it even more confusing. I expect that the
final version, once posted might read a bit differently (that is, including
the use of terms the current version says should be avoided).

  I just didn't want the TCs making decisions on something that has no
official standing and has not been made publicly available.

Regards,

Mary


> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: Monday, September 24, 2007 1:30 PM
> To: opencsa-ms@lists.oasis-open.org
> Cc: Patil, Sanjay; Mike Edwards; Martin Chapman; Ashok Malhotra; David
> Booz; Michael Rowley; Blohm, Henning; Bryan Aupperle; Simon Holdsworth
> 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
> --