Use of "intended" in the EFSP

[paulbuck]

There are 4 uses of the word "intended" in the EFSP. Consider using a term that is more definitive. Intends to me suggests something is possible, for a process I think it would be helpful to be more concrete/directive.

[waynebeaton]

I get your point. It's not enough to passively say that something is intended for something or other, but rather we should be specific.

I'm thinking that we just chop it out of the definition of Specification:

Specification: 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.

I'm thinking that it's actually incorrect to say that a specification is intended to enable the development of Compatible Implementations; that's what Final Specifications are for.

The definition of Release isn't quite right either.

Release: A Specification Version intended for ratification as a Final Specification.A build of Project artifacts produced by a Specification Project for delivery to the Specification Committee for Ratification as a Final Specification.

I'm thinking that Release and Specification Version are actually synonyms. Although, it may be the case that major or minor releases are Specification Versions (and service releases are not). That is, a Specification Version is a Release that is brought to the Specification Committee for ratification and transmogrification into a Final Specification.

I'm thinking that we just drop this sentence:

The Scope of a Specification Project is intended to inform companies and individuals so they can determine whether or not to contribute to the Specification.

Again, I'm not convinced that it's actually 100% correct and don't feel that it adds value anyway.

I killed the use of the term under Milestone Builds a while back:

Leading up to a Release, a Specification Team must produce at least one Milestone Build. Milestone Builds and Release Candidates are "almost Releases" intendedshould be staged for adoption and testing by early-adopters.limited distribution to key stakeholders to solicit feedback. No formal Reviews are required for Milestone Builds.

[paulbuck]

I agree with your proposed edits regarding the usage of "intends". Feel free to close this issue.

[waynebeaton]

What I've proposed for Release isn't quite right. A service release is a release, but is not delivered to the specification committee.

Defining Release is relatively hard. I tend to think of releases as being more than just code/content, but that's really what they are.

Here's what I'm thinking:

Release :: A final aggregate build of Specification Project artifacts produced at the end of a Release Cycle.

and

Specification Version :: A Release that is delivered to the Specification Committee for ratification as a Final Specification. A Specification Version is either a Major Release or a Minor Release.

[waynebeaton]

Still not quite right...

If I'm interpreting the IP Policy correctly, all releases must be specification versions.

By participating in the Specification Development Project for a particular Specification Version at the time of release of a Final Specification of that Specification Version, a Participant grants the Patent License with respect to all Essential Claims in the Final Specification for that Specification Version, and all such Essential Claims will be Committed Essential Claims.

The difference is that a Service Release Specification Version does not require a Review or ballot to become a Final Specification.

Note that the IP Policy defines Specification Project but not Specification Development Project; I interpret these to be synonyms.