[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 119: alternate proposal
On monday's extended call, I took an AI to send out an alternate proposal for issue 119. Before I get into the proposal, I would like to lay out my thoughts about conformance to CAA spec: I see CAA as something that is very similar to JSR 250: common things (annotations & API) defined in a central place that can be reused by different C&Is. This provides consistency and prevents unnecessary duplication. Certainly a "Good Thing". As such, I don't know what claiming conformance to the CAA means (with one caveat mentioned below). It is a collection of APIs and annotations, that have to be tied together by a C&I. The Java C&I happens to use all of the APIs and annotations. Spring and EE C&I may not. [I did look at JSR 250 wordings, unfortunately, the spec isn't as rigorous wrt conformance as we are, so the JSR wordings can't be used directly] The proposal in this email is for the conformance section of both Java C&I and Java CAA. It is based on the proposal (read: stole their wordings) that is being discussed in the SCA policy TC. The CAA section basically says that this spec contains things that are meant to be included/used by other specs. If another spec uses the annotations/API then it must comply with its requirements. The Java C&I section says that a conformant implementation must conform to everything that is in Java C&I + Java CAA. In addition to APIs and annotations, the CAA spec also defines <interface.java>. An implementation may support this without supporting any of the Java C&Is and may want to claim conformance to that without claiming conformance to all of the CAA. I have included wordings to allow that. Note that the proposal does not define conformance targets. Bryan's proposal does do that. I don't see why the two cannot be combined. The only quibble I have with the conformance targets as defined in Bryan's proposal is that it only defines the target "SCA runtime". I think, in addition, we do need a target for compliant Java classes. We do have restrictions on various annotations. A class that violates the restriction is non-compliant and IMHO it is important to say that (I have not included statements for complaint java classes in this proposal). Also note that "Appendix ??" in the proposal below refers to the appendix that will be created for each spec that lists all the statements that contain RFC 2119 keywords. Proposal for Java C&I: --------------------- An implementation that claims to conform to this specification MUST meet the following conditions: 1. The implementation MUST conform to the SCA Assembly Model Specification [Assembly]. 2. The implementation MUST conform to the SCA Policy Framework Specification [Policy]. 3. The implementation MUST comply with all statements in Appendix ??, notably all mandatory statements have to be implemented. 4. This specification includes all the APIs and annotations defined in the Java Common Annotations and APIs Specification [JavaCAA], therefore the implementation MUST comply with all the statements in Appendix ?? of [JavaCAA], notably all mandatory statements have to be implemented. For CAA: ------- An implementation that claims to support <interface.java> MUST comply with all statements in Appendix ?? with the tag prefix of "JCA3". [do we need transitive closure for all dependent tags?] The annotations and APIs defined in this specification can be included and used by other SCA Java specifications on an 'à la Carte' basis, as needed by those specifications. An implementation that conforms to a SCA Java specification that includes and uses annotations/APIs defined in this specification, is required to comply with all the statements in Appendix ?? of this specification that apply to the annotations/APIs that are used. Comments? -Anish --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]