OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sca-assembly] REOPEN ISSUES 132 and 149: Update to Sanjay'sProposal

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:
450A8AE74D5084479F79A0F5016285EB8B9D101B5B@ALTPHYEMBEVSP10.RES.AD.JPL" type="cite">

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

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 development community.

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 with anyone.

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.

450A8AE74D5084479F79A0F5016285EB8B9D101B5B@ALTPHYEMBEVSP10.RES.AD.JPL" type="cite">

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?

450A8AE74D5084479F79A0F5016285EB8B9D101B5B@ALTPHYEMBEVSP10.RES.AD.JPL" type="cite">

c.      An adapted version of the SCA Assembly Test Suite for testing the implementation type is created and is made publicly available to its prospective development community.

Again, my concerns about the narrow focus.

450A8AE74D5084479F79A0F5016285EB8B9D101B5B@ALTPHYEMBEVSP10.RES.AD.JPL" type="cite">

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.

450A8AE74D5084479F79A0F5016285EB8B9D101B5B@ALTPHYEMBEVSP10.RES.AD.JPL" type="cite">

4.      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?

450A8AE74D5084479F79A0F5016285EB8B9D101B5B@ALTPHYEMBEVSP10.RES.AD.JPL" type="cite">

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 both ways.

450A8AE74D5084479F79A0F5016285EB8B9D101B5B@ALTPHYEMBEVSP10.RES.AD.JPL" type="cite">

  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 the specs.

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?


450A8AE74D5084479F79A0F5016285EB8B9D101B5B@ALTPHYEMBEVSP10.RES.AD.JPL" type="cite">


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