Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Specification Committee call agenda, October 3/2018
This may be related to the "includes" vs. "references" discussion, but I think that I'm asking a different question.

Let me try this again.
  • We have profile P. 
  • Profile P includes Specification A. 
  • A has three optional parts a, b, and c. 
  • P explicitly requires that a be implemented, but is silent on b and c.
  • To implement all of P, there is no implicit requirement to implement b and c.
To meet the requirement that I fully implement P including all optional parts, must I also implement b and c?

That is, does "optional parts" refer just to P, or does it imply that all

Does the answer change if A is  is a dependency or is included?

> We agreed that at some point it will be desirable to refactor the EE4J project
> to create a Top Level Project specifically for Specification Projects related
> to Jakarta EE.
No, we didn't agree on that.

Fair enough. Your summary is more accurate.

Regardless, it is out of scope for this discussion.

Wayne

On Wed, Oct 3, 2018 at 11:40 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
Wayne Beaton wrote on 10/03/2018 07:56 PM:
Depends on the requirements of the JSP specification.  If the JSP specification doesn't depend on some optional elements of the Servlet specification, the full JSP CI wouldn't need to implement those optional elements of the Servlet specification.  In general, a JSP CI wouldn't be implementing the Servlet spec at all, but would require a Servlet CI to run on.

This is what I was hoping for. There are no inferred requirements for prerequisite specification implementations. Can I safely assume that the same is true for Profiles?
No.

This is back to the discussion we had previously about whether the spec is a dependency or is included.  Servlet is a dependency of JSP.  Servlet is included in the Web Profile.

What does it mean to "add" a Compatible Implementation to a Final Specification?

We have had previous discussions regarding a requirement to keep track of Compatible Implementations and the ability to add new ones to the list as they certify. I've come to regard this as part of the metadata of a Final Specification. 

On a related note, it seems like a good idea to me to have some sort of standard metadata format to describe the various pieces of a Final Specification. But that's an implementation detail.
The lifetime of this information is different than the lifetime of a specification, so I would keep them separate.


As I've said previously, the specification document should not refer to any implementations. 

+1
 
The Project Review should include information about Compatible Implementations.  Once the review is complete, there's no need to update that information, but we might want to separately maintain a list of Compatible Implementations for a given spec.

"might want" suggests that it's up to the Specification Committee to decide what to do. My understanding is that the notion of Compatible Implementations takes the place of the notion of a single reference implementation. My expectation then, is that that means that we have a requirement to provide pointers to Compatible Implementations as part of a Final Specification.
Yes, but that's different than whether we want to maintain a separate list of Compatible Implementations that evolves over time as more implementations are produced and become compatible.


Release Review records persist, but they don't feel like the right means to provide this.
To provide the evolving list of Compatible Implementations?  I agree.



--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Meet us at EclipseCon Europe 2018: LUDWIGSBURG, OCTOBER 23 - 25

Back to the top