[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] [ISSUE 132] Rebuttal: Against the use of portability and functions as reasons for requiring one of the existing 4 languages
I do not see any reason to believe that we cannot define a conformance test for SCA Assembly. If we are able to do so, we would not need to require support for the core languages. I assert that 1) We should not assume that we cannot define a compliance test until we have tried. 2) An assembly spec that places requirements on internal implementation languages is flawed.
Finally, I was present in IBM when we started work on SCA. Language independence and encapsulation of implementation was an explicit objective. The IBM architecture leadership would have vetoed any assembly spec with this requirement.
Dr. Donald F. Ferguson
Corporate Senior Vice President
Chief Architect Products and Technology
You did not addressed the points I was hoping you would. In fairness, I probably did not explain them clearly. Here's another try.
As background, I think we all agree on the value of strong, verifiable conformance and clear tests that can perform that task. No one is arguing that point. And no one is claiming vendors should be allowed to "invent" or otherwise modify portions of the conformance test suite with abandon :-). I'm sure we can safely assume everyone understands the virtues of conformance test suites and avoid rehashing them here.
Given that, my point is that a vendor should be able to claim conformance to the SCA Assembly specification without being required to be conformant with one of the official languages. One of the reasons given for not accepting Microsoft's request to change this requirement was, "If there were no requirement to support one of the implementation types covered by the Open CSA Member Section, this would mean that end users could have no assurance that the SCA runtime concerned really provides the functions laid down by the SCA specifications". In a nutshell, I don't think the statement is accurate and I believe conformance tests that do not rely on a specific implementation type (other than composites) can be developed for Assembly. The purpose of my email was to outline how that could be accomplished.
I would not characterize this approach as more "open" since it still hold vendors (or open source projects) accountable in very defined and verifiable ways. It is perhaps more "modular" and arguably will promote portability, which is lacking with SCA.
What would I like to see? Basically, I would like a runtime to be able to claim conformance to the SCA Assembly Specification without having any requirements by way of a programming language. In other words, it should be possible for a runtime to pass the Assembly conformance suite without having to support any of the sanctioned programming language specifications. One proviso which could be attached to claim conformance is that a vendor (or open source project) would be required to make any artifacts required to run the tests (excluding the runtime) available under the same license terms as the OASIS tests. Given the current test suite requires vendor-specific code, this probably should be a requirement regardless of the present proposal.
I believe this approach would address the concerns raised by a number of parties during the public review. What issues do you see with this approach or is it acceptable in your view?
On Jun 23, 2009, at 4:03 PM, Mike Edwards wrote:
stated otherwise above: