Specification track without notion of TCK

[DBees]

As some simpler specification projects may either

• not need a TCK, or
• start out without needing that notion, but later develop the need,

We should consider revising the EFSP to allow the "no TCK defined" track.

[waynebeaton]

The TCK is generally used as a means of proving that an implementation correctly implements the specification.

In the case where there is no TCK, is there still some notion of proving correctness?

[starksm64]

Specifications without TCKs are the norm in the bulk of the specification world. TCKs are replaced with interop test suites and events. TCKs are a significant burden and I can see the value in spinning up a specification that deems it unnecessary to have a formal TCK.

[waynebeaton]

Specifications without TCKs are the norm in the bulk of the specification world. TCKs are replaced with interop test suites and events. TCKs are a significant burden and I can see the value in spinning up a specification that deems it unnecessary to have a formal TCK.

Are TCKs, then, a specific example of a more general concept?

Should we remove the formal notion of a TCK from the process? Is it enough to say that a compatible implementation must "fulfill the requirements of the specification"? Individual specifications could then, for example, indicate that in order to fulfill the requirements of the specification and implementer must pass an identified TCK?

[starksm64]

I think "fulfill the requirements of the specification, including any testing requirements, if they exist" would cover all cases.

[DBees]

Test suites, plugfests, certification testing programs, TCK, golden reference code, test events, etc. are all variations on a theme. I don't argue that TCK needs be removed, but that it should be an optional part of the specification process. For example a group may first wish to develop a specification, then at a later stage develop one of these approaches.