OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue 132: Proposal


Title: Issue 132: Proposal

With the current conformance criteria for SCA Runtime (section 13.2 of the SCA Assembly specification), it is not possible for vendors to claim conformance with SCA by using runtimes that support only proprietary SCA implementation types (and do not support any of the OpenCSA defined standard implementation types). I think it is in the interest of the OpenCSA member companies to promote a broader adoption of the SCA standard and not introduce any hurdles that are not absolutely necessary. As it was apparent (at least to me) from the discussion on todays (10/20) SCA Assembly TCs conference call, we are ourselves not fully convinced that the current conformance criteria is necessary. It seems that we are ready to maintain the status quo of the current conformance criteria primarily because the alternative of defining a well thought out and commonly agreed upon solution along with all the right legalese is going to be challenging and time consuming. While I agree with this concern, I dont think maintaining the status quo provides us the right path forward.

If we must come up with a quick solution, I would propose that we take the route of relaxing the conformance requirements and make the SCA standard more accessible (from a conformance perspective) now -- in its very first release. As part of a future release, we can then think about how to set up a level playing field by imposing the same IP terms for both the OpenCSA defined implementation types and the vendor defined implementation types.

Please see below for my proposal for resolving the Issue 132. The language of the proposal many need some tweaking but I hope that it has sufficient clarity to be considered as a formal proposal.

Thanks,

Sanjay

Proposal:

Resolve the Issue 132 by replacing the current text of Section 13.2 (SCA Runtime) with the following (which essentially removes the item 4 and updates the item 3 of the current text) :

An implementation that claims to conform to the requirements of an SCA Runtime defined in this specification MUST meet the following conditions:

1.      The implementation MUST comply with all statements in Appendix C: Conformance Items related to an SCA Runtime, notably all MUST statements have to be implemented.

2.      The implementation MUST conform to the SCA Policy Framework v1.1 Specification [Policy].

3.      The implementation MUST support at least one implementation type standardized by the OpenCSA Member Section or comply with the following rules for at least one of the other implementation types:

a.      The implementation type is defined in compliance with the SCA Assembly Extension Model (Section 10 of the SCA Assembly Specification).

b.      A document describing the mapping of the constructs defined in the SCA Assembly specification with those of the implementation type is made publicly available. Such a document should help in understanding how SCA components can be developed using the implementation type, how these components can be configured and assembled together (as instances of Components in SCA compositions). To get an idea about the purpose and scope of such a document that describes the implementation type, see the Client and Implementation specifications for the implementation types standardized by the OpenCSA Member section.

c.      An adapted version of the SCA Assembly Test Suite for testing the implementation type is created and is made publicly available.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]