Re: [sca-j] Issue 119: alternate proposal

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

I think it makes sense to talk about conformance claim to contributions 
in assembly (or at least start there). But I doubt if assembly will say 
anything about conformance claims wrt Java classes, which I think are 
equally important (wrt claiming conformance) -- contributions are 
aggregation of conformant constituents + some additional requirements 
wrt contribution.xml etc.

-Anish
--

Bryan Aupperle wrote:
> 
> Martin's scenario that a vendor might produce a contribution providing 
> some functionality and want to clam that the contribution conforms to 
> the CAA specification is worth supporting.  However, I do not believe 
> that it makes sense to claim that a contribution conforms to the CAA 
> spec unless it is also possible to claim that the contribution conforms 
> to the Assembly and Policy specs.  IMHO, the discussion needs to take 
> place in the Assembly TC first, and then the direction for the other 
> TC's will be clear.
> 
> Bryan Aupperle, Ph.D.
> STSM, WebSphere Enterprise Platform Software Solution Architect
> 
> Research Triangle Park,  NC
> +1 919-254-7508 (T/L 444-7508)
> Internet Address: aupperle@us.ibm.com
> 
> 
> *Anish Karmarkar <Anish.Karmarkar@oracle.com>*
> 
> 02/06/2009 03:01 AM
> 
> 	
> To
> 	OASIS Java <sca-j@lists.oasis-open.org>
> cc
> 	
> Subject
> 	[sca-j] 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
> --
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
>