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: FW: [sca-assembly-comment] Microsoft's response for Public Review of SCA Assembly Model v1.1 - 15 day review

-----Original Message-----
From: Michael Champion [mailto:Michael.Champion@microsoft.com] 
Sent: 04 March 2010 04:50
To: sca-assembly-comment@lists.oasis-open.org
Subject: [sca-assembly-comment] Microsoft's response for Public Review of SCA Assembly Model v1.1 - 15 day review

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.

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

This publicly archived list offers a means to provide input to the OASIS Service Component Architecture / Assembly (SCA-Assembly)

In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: sca-assembly-comment-subscribe@lists.oasis-open.org
Unsubscribe: sca-assembly-comment-unsubscribe@lists.oasis-open.org
List help: sca-assembly-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/sca-assembly-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-assembly
Join OASIS: http://www.oasis-open.org/join/

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