Microsoft's response for Public Review of SCA Assembly Model v1.1 -15 day review

[Michael Champion <Michael.Champion@microsoft.com>]

I am very sorry to learn that the Assembly TC chose to abandon the productive discussion that our comment [1] had initiated by taking no action [2]. I am particularly distressed to see the Microsoft comment characterized as a request for "loosening" the conformance requirements, since the request was to do the opposite --  Microsoft asked the TC to clarify the *technical* criteria implementers could use to check the conformance of an implementation of SCA Assembly, and to do so in a language/implementation-independent manner.

The net effect of rejecting Microsoft's comment is that no one outside the small community that has drafted the SCA Assembly specification for the given four languages may claim conformance - even though the specification is supposedly language neutral. 

As it stands now, it is not possible to claim that SCA is a language independent standard that supports open platforms because it explicitly restricts conformance to those implementation that use an arbitrary set of languages (C/C++/Java/BPEL). If one programs in Python, PHP, Ruby, C# or Visual Basic, for example, there is no way for them to build a conformant implementation. Why would OASIS create an "open" standard and then restrict "conformant" implementations to just a few programming languages? 

In discussions of our proposal, the TC expressed a mandate that implementers pass a test suite before they can claim conformance [7]. We have a major concern that OASIS should not take a position regarding conformance of each implementation of an OASIS Standard, other than to specify the conformance requirements in the Standard. In the past, OASIS has ratified specs, and implementers implemented them and claimed conformance as appropriate. The ultimate conformance judgment has been in the eyes of the users and customers. Test suites are useful artifacts which can improve the implementation process, but it is up to the marketplace to hold the implementers accountable for the quality and conformance of their implementations.
                                                          
I believe that SAP's proposal [3] to modify SCA Assembly conformance criteria to address the Microsoft [5] and Siemens [6] issues could meet both the TC's needs and our concerns, as long as the TC makes the following changes in that proposal: (remember the SAP's proposal called for removal of  the item "3. The implementation MUST support and comply with at least one of the OpenCSA Member Section adopted implementation types."):

1) The TC creates language-independent test suites [4], and provides them freely to the public with no licensing requirements.
2) The TC recommends that the implementers use the freely available tests to validate their implementation.  
3) The TC can recommend that the implementers provide documentation to their customers that demonstrate how their derived Implementation Type has used the SCA Assembly extensibility mechanism. To facilitate that, the TC could create a template for such documentation which will again be freely available to the community, with no licensing requirements.

With all these suites and documents, it is between the marketplace and the implementers to make the best use of such documentation. OASIS cannot be in the position of reviewing implementers' test results and assigning scores or pass/fail evaluations.

Providing detailed and accurate product documentation and tests are increasingly important aspects of modern software engineering that OASIS can evangelize, but not legislate. And it is important to note that it is ultimately up to the customers, and not OASIS, to demand conformance or pass judgment.

Sincerely,
Michael Champion

[1] http://lists.oasis-open.org/archives/sca-assembly-comment/200906/msg00001.html 
[2] http://lists.oasis-open.org/archives/sca-assembly/201001/msg00222.html 
[3] Sanjay Patil's proposal: http://lists.oasis-open.org/archives/sca-assembly/200910/msg00047.html 
[4] http://lists.oasis-open.org/archives/sca-assembly/200910/msg00070.html 
[5] JIRA 132 (Microsoft): http://www.osoa.org/jira/browse/ASSEMBLY-132  
[6] JIRA 149 (Siemens): http://www.osoa.org/jira/browse/ASSEMBLY-149 
[7] http://lists.oasis-open.org/archives/sca-assembly/200910/msg00072.html