Re: [sca-j] Issue 119: YAAP

[Mike Edwards <mike_edwards@uk.ibm.com>]

Anish,

This is good.

Reading the proposal led me to think
harder about the wording and about the spec itself - comments are inline

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:	OASIS Java <sca-j@lists.oasis-open.org>
Date:	20/03/2009 07:21
Subject:	[sca-j] Issue 119: YAAP

---

Yet Another Alternate Proposal for issue 119:

This is based on my earlier alternate proposal [1], the discussion on 
mailing list related to that proposal, discussion on the concall and the
conformance section in Assembly [2]. I'm sure I haven't gotten 
everything right, so feedback is most welcome.

1) For CAA Spec add a new conformance section:

Conformance

The XML schema pointed to by the RDDL document at the namespace URI, 
defined by this specification, are considered to be authoritative and 
take precedence over the XML schema defined in the appendix of this
document.

There are three categories of artifacts that this specification defines
conformance for: SCA Java XML Document, SCA Java Class and SCA Runtime.

SCA Java XML Document

An SCA Java XML document is an SCA Composite Document, or an SCA 
ConstrainingType document, as defined by the SCA Assembly specification
Section 13.1 [SCA-ASM], that uses the <interface.java> element. Such
an 
SCA Java XML document MUST comply with the SCA Assembly specification 
requirements, SCA Policy Framework [SCA-Policy] requirements and the 
requirements specified in Section 3 of this specification.

<mje>
Not the fault of this proposal, but the use
of "section 3" in the wording raises the question
of whether section 3 actually contains all
the normative statements that apply to
<interface.java/>.
I think the answer is "no" since
only two annotations are dealt with in that section -
@Remotable and @Callback.  I believe
that it is possible to annotate an interface with
Policy-related annotations.
Probably the simplest way to handle this
is to simply add a list of the other allowed 
annotations to a new subsection at the end
of section 3.  We will also need to add a
normative statement that interfaces with
all these annotations MUST be supported,
since there isn't one at the moment.
</mje>

SCA Java Class

An SCA Java Class is a Java class that complies with Java version 1.5 
and MAY include annotations and APIs defined in this specification. An
SCA Java Class that uses annotations and APIs defined in this 
specification MUST comply with the requirements specified in this 
specification for those annotations and APIs.

<mje>
OK as long as the term "Java class"
also covers "Java interface"
</mje>

SCA Runtime

The APIs and annotations defined in this specification are meant to be
used by Java-based client and implementation models in either partial or
complete fashion. A Java-based client and implementation model 
specification that uses this specification specifies which of the APIs
and annotations defined here are used. The APIs and annotations an SCA
Runtime has to support depends on which Java-based client and 
implementation model specification the runtime supports. For example, 
see the SCA Java Client and Implementation Specification [SCA-JCI].

An implementation that claims to conform to this specification MUST meet
the following conditions:
1.The implementation MUST meet all the conformance requirements defined
by the SCA Assembly Model Specification [SCA-ASM].
<mje>What happened to the Policy spec?</mje>
2.The implementation MUST support <interface.java> and MUST comply
with 
all the normative statements in Section 3.
3. The implementation MUST reject an SCA Java XML Document that does not
conform to the sca-interface-java.xsd schema.
3.The implementation MUST support the WSDL to Java and Java to WSDL 
mapping and MUST comply with all the normative statements in Section 10.
<mje>
I think there has to be another requirement
for the runtime to accept a Java interface
class as defined by section 3, which might
be implied by #2 here, but it isn't explicit...
</mje>
[Do we need a requirement for being JRE 1.5 compliant?]



2) For CAA Spec add a new conformance section:
<mje> You mean Java C&I spec? </mje>

Conformance

The XML schema pointed to by the RDDL document at the namespace URI, 
defined by this specification, are considered to be authoritative and 
take precedence over the XML schema defined in the appendix of this
document.

There are three categories of artifacts that this specification defines
conformance for: SCA Java C&I Composite Document, SCA Java C&I
Contribution Document and SCA Runtime.

SCA Java C&I Composite Document

An SCA Java C&I Composite document is an SCA Composite Document, as
defined by the SCA Assembly specification Section 13.1 [SCA-ASM], that
uses the <implementation.java> element. Such an SCA Java C&I
Composite 
document MUST comply with the SCA Assembly specification requirements,
SCA Policy Framework [SCA-Policy] requirements and the requirements 
specified in Section 9 of this specification.

SCA Java C&I Contribution Document

An SCA Java C&I Contribution document is an SCA Contribution Document,
as defined by the SCA Assembly specification Section 13.1 [SCA-ASM], 
that uses the contribution metadata extensions defined in Section 10. 
Such an SCA Java C&I Contribution document MUST comply with the SCA
Assembly specification requirements and the requirements specified in 
Section 10 of this specification.

SCA Runtime

An implementation that claims to conform to this specification MUST meet
the following conditions:

1. The implementation MUST meet all the conformance requirements defined
by the SCA Assembly Model Specification [SCA-ASM].
2. The implementation MUST meet all the conformance requirements defined
by the SCA Policy Framework Specification [SCA-Policy].
3. The implementation MUST reject an SCA Java Composite Document that 
does not conform to the sca-implementation-java.xsd schema.
4. The implementation MUST reject an SCA Java Contribution Document that
does not conform to the sca-contribution-java.xsd schema.
4. The implementation MUST meet all the conformance requirements defined
by the SCA Java Common Annotations and APIs Specification [JCAA].
5. This specification includes all the APIs and annotations defined in
the Java Common Annotations and APIs Specification [JCAA], therefore
the implementation MUST comply with all the statements in Appendix YYY:
Comformance Items of [JavaCAA], notably all mandatory statements have to
be implemented.
6. The implementation MUST comply with all statements in Appendix XXX:
Conformance Items related to an SCA Runtime, notably all mandatory 
statements have to be implemented.
<mje> How does #4 differ from #5 above?
</mje>



May the throwing of rocks commence.

-Anish
--

[1] http://lists.oasis-open.org/archives/sca-j/200902/msg00049.html
[2] 
http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/31740/sca-assembly-1.1-spec-cd03.pdf

---------------------------------------------------------------------
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

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU