Hi Jim, Jeff,|
On 2/24/11 10:40 AM, Jim Marino wrote:
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
This point, at least, I understand. As I understand it, the test
suite is normative material, although not, as you note, a criteria
If I understood him correctly, during the bindings call this
morning, Mike Edwards indicated he disagrees with me, but I do think
that a key part of the test suite is to validate the normative
statements of the spec. If you can't write a test for a particular
normative statement, or a particular clause of a normative
statement, then perhaps the normative statement shouldn't be
normative. Or maybe you write the test, and realize while thinking
through all the cases that the normative statement leaves
possibilities out. Or maybe writing the tests highlights an area
where there's too much implementation leeway, and more normative
statements might be in order. The best way to find any of that out
is to write a test suite. As I recall, all of these situations arose
during the development of the test suites.
Now that we have the tests, do we need the them to run against two
implementations? Personally, I'd be satisfied by one.
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
I concur with Jim here. If an implementation professes to implement
the spec, but then fails the test suite, that's a fairly obvious
point that the marketplace can sort out. Vendors might declare "we
pass 90+%" for example. Leave it to the end users to figure out
whether that last X percent matters.
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
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
Sent: 22 February 2011 20:08
To: OASIS Assembly
Subject: Re: [sca-assembly]
Concrete Exit Criteria for t! he SCA Assembly TC -
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 issues of portability and
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
Sr. Director, Oracle Fusion Middleware
Web Services Standards
Oracle Parkway, M/S 2OP9
Shores, CA 94065