On Feb 23, 2011, at 3:05 PM, Jeff Mischkinsky wrote:
On Feb 23, 2011, at 11:34 AM, Jim Marino wrote:
I guess I may now be even more confused, probably because of my ignorance of OASIS rules. Why would the exit criteria for the TC require an implementation to adhere to something that is not normative, specifically running and passing the TC-supplied test suite? Also, who determines whether a runtime passes or not?
I am having a hard time pinning down your confusion.
I guess my confusion was not clear :-)
I understand that the the TC-supplied test suite is not normative and that an entity responsible for an SCA runtime can legitimately claim conformance without running the TC-supplied test suite. It is up to the court of public opinion to validate conformance claims.
My question was why the exit criteria would require two runtimes to also implement/run non-normative TC artifacts? That seems inconsistent with how other non-normative aspects of the specification are handled, such as optional sections, which are not required. Are there other OASIS TCs that have adopted exit criteria which require implementations to pass conformance tests?
There is a test suite that has been developed by the TC. When you take your implementation and run it through the test suite, you get an "answer". That's the answer you are looking for.
The exit criteria require that there be 2 independent impls that run the test suite, and get answer that says "yes" (or all green ;-).
Did you intend to say "the proposed exit criteria"? As it currently stands, the TC charter says nothing about mandating an implementation run the test suite. Assuming exit criteria were adopted that mandated the test suite be passed by two independent runtimes, how would that be done? In other words, who decides and verifies the tests were "all green"? Does the entity responsible for a runtime need to make the test suite and integration code (or binaries) required to plug the runtime into the test suite publicly available? Or is it enough for the entity to claim its runtime passes?
On Feb 23, 2011, at 10:54 AM, Martin Chapman wrote:
I think you are confusing the normative-ness of the test suite with TC exit criteria.
You are correct that to claim conformance you donít have to pass the TCís test suite, but that is different from the TC saying that in order to progress the spec to Committee Specification/OASIS Standard we want two implementations passing the TCís test suite.
From: Jim Marino [mailto:email@example.com]
Sent: 22 February 2011 20:08
To: OASIS Assembly
Subject: Re: [sca-assembly] Concrete Exit Criteria for t! he SCA Assembly TC - Proposal
The first bullet makes sense to me. Concerning the second, my understanding is the TC Test Suite is not normative and the only thing required for conformance is for the entity responsible for a particular runtime to declare that it adheres to the normative portions of the Assembly Specification. In other words, it should be valid for a runtime to claim conformance that supplies its own test suite, which may or may not be based on the TC one. This essentially goes back to using the "court of public opinion" to judge conformance claims as opposed to something akin to a TCK.
On Feb 18, 2011, at 6:19 AM, Mike Edwards wrote:
I propose the following as the Exit Criteria to be adopted by the SCA Assembly TC:
"The Concrete Exit Criteria for the SCA Assembly V1.1 specification are that:
o there shall be 2 independent SCA runtimes that are compliant with all normative portions of the
specification as described in! Section 12.2 of the SCA Assembly V1.1 specification
o the 2 independent runtimes shall pass the Test Suite for SCA Assembly as described in the document
'TestCases for the SCA Assembly Model Version 1.1 Specification' "
I believe that this is sufficient to cover:
- the question of conformance to the spec
- the issues of portability and interoperability
since the test suite is a pretty thorough examination of conformance to the spec (there are testcases for
all normative statements with testable & observable consequences) and the test suite is also a test of portability,
since the test suite has an extensive set of artifacts that are ported to each runtime and interoperability is
checked through the use of Web services being used between the SCA runtime and a non-SCA (JAXWS) client.
Dr Mike Edwards
Mail Point 146, Hursley Park
Winchester, Hants SO21 2JN
SCA & Services Standards
Co-Chair OASIS SCA Assembly TC
IBM Software Group
Unless stat! ed otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Jeff Mischkinsky firstname.lastname@example.org
Sr. Director, Oracle Fusion Middleware
and Web Services Standards
500 Oracle Parkway, M/S 2OP9
Redwood Shores, CA 94065