Clarify the nature of a "Specification"

[waynebeaton]

The EFSP defines Specification as:

A collection of Application Programming Interface (API) definitions, descriptions of semantic behavior, data formats, protocols, and/or other referenced specifications, along with its TCK, intended to enable the development and testing of independent Compatible Implementations.

It's implied, but not explicitly stated that a Specification Document is what provides "descriptions of semantic behavior, data formats, protocols, and/or other referenced specifications".

In concept, a specification is the composition of:

• the description of behavior, formats, and protocols;
• supporting technical artifacts; and
• a means of validating that an implementation conforms to the description of behavior, formats, and protocols.

In practical terms, a specification is, then, the composition of:

• a Specification Document;
• technical artifacts (e.g., an API); and
• a TCK.

Later, the definitions section describes a Specification Version as a specific version of a Specification; we then later further describe it as:

Each Specification Version references specific versions of its constituent artifacts. These artifacts include the Specification Documents, zero or more other Specifications, one or more Compatible Implementations licensed under an Open Source License, and exactly one associated TCK for this Specification.

That is, we add the inclusion of one or more Compatible Implementations.

The diagram shows the TCK and Compatible Implementations as connected, but separate (the relationship appears aggregate rather than composite).

The diagram for Final Specifications near the end of the document suggests/reinforces an aggregate relationship between a Specification Version and a TCK, and a tigher composite relationship between all artifacts for a Final Specification.

To my mind, the Compatible Implementations attached to a Specification Version or Final Specification must always be aggregate; there's not guarantee that any particular Compatible Implementation will persist as long as the Final Specification that references it.

[bjhargrave]

To my mind, the Compatible Implementations attached to a Specification Version

By definition, an implementation can only be a Compatible Implementation of a Final Specification. Thus a Specification Version, being unratified and non-Final, cannot have any Compatible Implementations. Only candidates that can become Compatible Implementations when/if the Specification Version is Ratified into a Final Specification.

[waynebeaton]

Agreed. Until a specification version is ratified and becomes a Final Specification, a Compatible Implementation is just an candidate.

[starksm64]

I don't see that this distinction of the relationship between the spec and a compatible implementation is important. All that we are looking for is that at the time of ratification, there was one demonstrable open source implementation that passed the associated TCK. This allows both some level of confidence in the TCK and an ability to view source code of a compatible implementation. We don't want to suggest that the ratifying compatible implementation holds any special status, that its choice of implementation is more valid that subsequent implementations, or anything that would tend to lend a dreaded reference implementation semantic back into the process.