[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] Issue 119: alternate proposal
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]