The notion of "Platform" adds no value

[waynebeaton]

The EFSP suggests that a profile may be designated as a platform, but provides no compelling reason to have this designation.

There are two references:

A Specification Committee may, at its discretion, elect to label one or more Profiles as a “Platform”.

and

• A Platform designation (this Super-majority must include a Super-majority of Strategic Members of the Working Group).

IMHO, it adds no value in the general case and should be removed.

By removing this, we are not adding any restriction on the ability of a specification to be labeled a "platform"; since the specification committee gets a vote when a new specification project is created or a new specification is added to an existing project, they effectively have control over the use of the term anyway.

As with other cases, a working group may opt to add this notion into their own specialization of the EFSP.

Am I missing something important @mmilinkov ?

[edbratt]

I believe the original thinking behind this may have been -- Platform is (or Platforms are) most likely the thing(s) that vendors will be most interested in implementing. The idea of a super-majority of strategic vendors was a realization that anything defined as a "Platform" would almost certainly imply implementation focused resource commitment from most if not all vendors. In recognition of this, the strategic member, super-majority voting requirement provides a very slight additional voting leverage for those specifications to the vendors who have opted in at the "strategic" level. This would be the case if the scope of specifications that contained the Platform (or Platforms) grows or shrinks or the number of Platforms specification grows or shrinks. Thus, anything with the designation "Platform" has farther reaching impact than do specific component specifications.

Among other things -- a Platform specification may describe it's own requirements (i.e. it may be more than the sum of it's component specifications); it may define how component specifications operate in combinations or in operational modes; it may define a list of component specifications -- beyond any of the individual component specifications; it may define a set of additional rules that implementations designated as Platform must adhere to. Generally (though I don't know how staunchly this is adhered to) Component specifications generally limit their external scope. They may have dependencies and, lately, the notion of Profiles has begun to creep into component specifications -- but component specifications don't attempt to act in the same broad-scope way as a Platform might.

If this distinction seems out of place with the ESFP, perhaps, rather than removing it, additional descriptive material could be added to clarify what distinguishes specification with the "Platform" designation from those that don't hold this designation.

[edbratt]

Additionally, at least in Jakarta EE, The Platform specifications provide a TCK that an implementation can pass, to meet the requirements of many component specifications compatibility requirements (i.e. A Jakarta EE Platform implementation need only needs to run the Platform TCK, to demonstrate compatibility with many Jakarta EE component specifications) -- without the obligation to also run those individual TCKs separately. This is another feature by which the Platform Specification is unique from component specifications.

[mmilinkov]

@edbratt I think that the EFSP concept of "Profile" does all of the things you've described as "platform". Do you disagree? A "Platform" is just an additional brand for a "Profile". Profiles also have a requirement to be approved by 2/3's of the strategic members.

I don't remember why we added this additional ceremony to calling a Profile a Platform. In retrospect it seems like overkill.

[edbratt]

I did not refresh my reading of the entire Spec. I only was responding to the issue description and the comments ahead of mine. If (a) this issue is actually suggesting that the quoted text is described elsewhere in the ESFP (i.e. it is redundant with text elsewhere), I might react differently. If (b) this issue is saying Platform as a concept does not belong in the Specification Process, I guess I would continue to push back on that.

In Jakarta EE, there is the Jakarta EE Platform and there is the Jakarta EE Platform, Web Profile. Personally, I don't think of the Jakarta EE Platform specification as a profile. The fact we (in my mind) sometimes erroneously refer to it sa "Full Platform" may be contributing to the confusion. Strictly speaking, I'd say the Platform Spec. is not considered a profile. My previous comments attempt to illustrate how, I think Platform specifications might be treated differently and possibly why there might be different criteria applied. To me, the designation seems to have purpose.

Of these two choices (a) or (b), which is this issue attempting to clarify? OR, have I missed the point entirely?

Allowing for a distinguishing characteristic (i.e. "Platform") to be conferred on "Uber" specs might allow for greater proliferation of other Profiles which may not need, nor qualify as a "Platform" -- for example, CDI and CDI Lite Profile. But perhaps we don't want to go in this direction.

Profiles were added in Java EE 6 (JSR 316). The result was two specifications Java Platform, Enterprise Edition 6.0, and Java Platform, Enterprise Edition Web Profile 6.0. Both came from the same JSR (also Managed Beans, but that's less relevant to this discussion).

[waynebeaton]

Any specification can aggregate other specifications and can specify how to demonstrate compatibility. There's nothing special about profiles or platforms in this regard.

I'm suggesting that the notion of "platform" isn't meaningful in the general case. I'm pretty sure that there is no notion of a Sparkplug platform or an AsciiDoc platform, for example.

Platforms and profiles are not mentioned in any of our other governance documents (please correct me if I'm wrong).

AFAICT, in the notion of "platform" (or "profile" for that matter) is significant only in the context of a compatibility/logo programme. That is, we could have a restriction that a compatibility programme may be built around compatible implementations of designated platforms or profiles (e.g., one can only use the "Jakarta EE compatible" logo when one implements a "platform").

However, compatibility programmes are not restricted in general to platforms or profiles. The Sparkplug Working Group could, for example, build a compatibility programme around the Sparkplug specification (by the definition in the EFSP, the Sparkplug specification could not be designated as a profile or platform).

A Specification that aggregates other Specifications by reference may be designated as a Profile.

That is, a regular specification can aggregate other specifications without being a profile; everything that we might actually want from a profile is possible in a specification. Further, a compatibility programme is built around whatever the working group decides that it is built around: the notion of a "platform" (or a even a "profile") doesn't need to be a formal concept in the EFSP to make that work. A working group can just say "this is a platform/profile" (whatever they decide that means), designate it as the thing that they're going to build a compatibility programme around, and we're done without it needing to be part of the EFSP.

[waynebeaton]

Recent discussions regarding mixing patent licenses has changed my mind. I am starting to believe that it may absolutely necessary to have a first class notion of profiles.

With regard to patent licenses, there is a difference, I think, a very significant difference between a specification that simply references another specification and a profile that aggregates specifications ("references" vs. "aggregates").

In the specification references another specification case (e.g., to implement Jakarta Pages you must also have an implementation of Jakarta Servlets), the implementer gets license grants for each of the specifications separately. That is, the implementer meets the requirements of the patent license for each specification individuals and receives the grants accordingly. In the Pages/Servlet example, just passing the TCK for Pages doesn't automatically grant any patent licenses for Servlet; the servlet TCK must be passed separately to get the corresponding patent grants.

In the aggregation case, it's a little different. When all aggregated specifications have the same patent license as the aggregating specification, then it's easy. When aggregated specifications have a mixture of patent licenses, it gets little more complicated. Having a formal notion of profile makes the conversation a easier and very clearly delineates between the "references" and "aggregates" schemes.

The EFSP states that:

A Specification that aggregates other Specifications by reference may be designated as a Profile.

I'm now thinking that this should be changed to indicate that specification that aggregates other specifications is designated as a profile. That is, when a specification aggregates other specifications, it is by definition a "profile".

This would mean that whether or not a specification aggregates other specifications becomes fundamental to the nature of the specification. A specification ballot is currently required to designate a profile; with a change such as I am suggesting, changing a specification to aggregate other specifications would automatically turn it into a profile, but only after approval by the specification committee via ballot.

Or maybe I'm trying too hard.

[starksm64]

Any a concrete manifestation of a specification that describes behavior and aggregates other specifications should be called a profile. The useful notion of a platform is more of a principal behind the working group members that are interested in profiles. The current use of platform in Jakarta EE for the largest aggregation would better be replaced by the term "full", or whatever equivalent alias, profile.

To the question of patent license mixing, it seems like the mixing possibilities just need to be enumerated, and the requirements to obtain the collection of patent grants clearly stated. I believe we are still waiting on the IP council providing guidance on this topic.

[Emily-Jiang]

I think profile works well for Jakarta EE as we can use web profile and then covert platform to full profile. For MicroProfile platform relase, it might be tricky to convert to MicroProfile full profile release.

[waynebeaton]

I think profile works well for Jakarta EE as we can use web profile and then covert platform to full profile. For MicroProfile platform relase, it might be tricky to convert to MicroProfile full profile release.

The EFSP doesn't make any requirement of what a profile is called. We can just say that "MicroProfile Platform" is a profile. If, at some later time the MicroProfile WG decides to make another profile, there may be some desire to disambiguate, but only if the naming after the hypothetical addition of an additional profile is somehow confusing.