Eric Johnson [mailto:firstname.lastname@example.org]
Sent: 26 April 2010 17:57
To: Estefan, Jeff A (3100)
Subject: Re: [sca-assembly] REOPEN ISSUES 132 and 149: Update to
In principle, I'm not against the notion of making SCA work
for other implementation types. In practice, I'm not sure that the
revised proposal gets us there.
Procedural question - what is the threshold for reopening closed issues?
Am I correct in thinking it is 2/3rds of all voting members (not just the
quorum)? I could track it down, but I suspect someone can answer quickly.
Although the issue hasn't been opened yet, comments follow.
On 04/23/2010 05:33 PM, Estefan, Jeff A (3100) wrote:
Raiser: Jeff A. Estefan / Mike Edwards
Target: SCA Assembly Model Specification Version 1.1
Description: Update to Sanjay’s Proposal in
Response to Issues 132 and 149
Proposal: The following is a recommended update to
Sanjay’s original proposal to address Issues 132 (http://www.osoa.org/jira/browse/ASSEMBLY-132)
and 149 (http://www.osoa.org/jira/browse/ASSEMBLY-149)
by replacing the current text of Section 13.2 (SCA Runtime) in the SCA Assembly
Model Spec with the language provided below. The original text of
Sanjay’s proposal is included as well as the inline updates showing
recommended updates. Note that this proposal also comes with the accompanying
documentation attached. Justification for reopening these issues is
articulated in the Justification section that follows the proposal.
Revised Sanjay Proposal:
An implementation that
claims to conform to the requirements of an SCA Runtime defined in this
specification MUST meet the following conditions:
1. The implementation MUST comply with
all statements in Appendix C: Conformance Items related to an SCA Runtime,
notably all MUST statements have to be implemented.
2. The implementation MUST conform to
the SCA Policy Framework v1.1 Specification [Policy].
3. The implementation MUST support at
least one implementation type standardized by the OpenCSA Member Section or comply
with the following rules for at least one
of the other implementation
a. The implementation type is defined
in compliance with the SCA Assembly Extension Model (Section
10 9 of the
this SCA Assembly Specification).
b. A document describing the mapping of
the constructs defined in the SCA Assembly specification with those of the
implementation type is made
publicly available to its prospective
Under what license? Many companies still include absurdly onerous
licensing terms on their software. I can imagine a license on an SCA
document of this sort that simply disallows any public discussion of the
quality of the SCA implementation/conformance, or of the document in
question. Consequently, this document, once it exists, may simply be of
no use to anyone who receives it, because they may not be able to discuss it
My take is that anyone claiming conformance must be willing to share
their specification of how they conform with as wide an audience as possible,
so that it can be subject to the broadest scrutiny. This doesn't need to
imply any sort of license to the underlying technologies, just the freedom to
copy the specification. In addition, should an SCA provider come up with
a useful way to specify conformance, the SCA community could benefit from being
able to see that alternate approach.
I've argued before, and I'm arguing again we could mandate one of any number of
useful licenses for accommodating these needs. Some Creative Commons
license (Creative Commons Attribution?) might be sufficient.
Such a document should help
in understanding how SCA components can be developed using the implementation
type, how these components can be configured and assembled together (as instances of Components in SCA
compositions). A template for such a document entitled "Implementation
Type Documentation Requirements for SCA Assembly Model Version 1.1
Specification" has been provided by this Technical Committee. The
contents outlined in this document template MUST be completed in order for an
implementation type to claim compliance with the SCA Assembly Specification.
To get an idea about the purpose
and scope of such a document that describes
the implementation type, see the Client and Implementation specifications for
the implementation types standardized by the OpenCSA Member section.
The "Implementation Type Documentation Requirements ..." document
sounds useful. Absent that document, I don't see a point to opening the
issue, as this document is at the heart of whether or not we can define our way
out of this box. I've long thought that the Assembly TC should actually
formally define what it means to be a valid implementation or binding
specification, so that we'd have a list of criteria that all the specs could
satisfy. I'd want to see such a document before addressing the question
of reopening the closed issues.
Question - once we have this document, don't we have to go back through and
validate that the existing specs satisfy the criteria?
adapted version of the SCA Assembly Test Suite for testing the implementation
type is created and is made
publicly available to its prospective
my concerns about the narrow focus.
A template for such a document entitled "Test Suite
Adaptation for SCA Assembly Model Version 1.1 Specification" has been
provided by this Technical Committee. The contents outlined in this
document template MUST be completed in order for an implementation type to
claim compliance with the SCA Assembly Specification.
Again, this document would be useful, independent of this issue, but absent it,
I don't see a point to reopening the closed issues.
The implementation MUST support one or
more binding types. If only one binding type is supported, it MUST be the
default SCA binding type, binding.sca.
Question: why wouldn't we extend the notion of conforming alternate
implementation types extended to alternate binding types?
Justification: The SCA assembly model should be made
agnostic to specific implementation technology to the maximum extent possible
so that it may be used as THE industry standard model for component and
composite assembly. Not all implementation technologies are
“open,” “standards-based,” and/or
“non-proprietary.” It’s simply not realistic.
This argument confuses the patents and copyrights covering the underlying
technology with the license that covers a specification how that technology
works with SCA. I agree with Jeff that this proposal is trying to have it
If the TC has a moral objection to such solutions,
then that is a personal bias and it should be clearly stated at the beginning
of each SCA-* specification.
I find the inclusion of this statement inappropriate. Are moral issues
ever just "personal"? And it is quite odd to consider that the
will of the TC could be misconstrued as "personal" as well. And
finally, the "moral" stance of the TC is, in fact, stated at the
beginning of each specification, in the form of the legal framework surrounding
This also misconstrues the problem. If we were even contemplating the
question, it isn't a moral one, so much as an ethical one. Does a company
"X", selling a product "Z", get to claim "Y", but
not have to show anyone but their customers (not even their prospective
customers, mind you) how they can validly claim "Y"?
Since the proposal above is premised on the addition of two new documents to
the suite of SCA, is this scope of work more appropriate for SCA 1.2?
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: