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:
Anish Karmarkar <>
02/06/2009 03:01 AM
To
OASIS Java <>
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
