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

[Jeff Mischkinsky <jeff.mischkinsky@oracle.com>]

hi,
   some comments/agreements/disagreements below;

On Apr 26, 2010, at 9:56 AM, Eric Johnson wrote:

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

OASIS does not, and cannot, specify the business practices (e.g.  
licenses that company choose to use for their products).
    NOTE: The IPR Policy only talks about what licenses obligated  
members are required to grant for their Essential Claims, it is NOT  
about products.

On the substance -
   I have no idea what "publicall available means" and besides which  
-- What is to stop me from producing a document which says only:
        "My product does some really cool mappings"
While absurd, this meets the requirement - and since no standards body  
is involved, there is no one who can OFFICIALLY make that determination.

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

nice sentiments and I agree with them. BUT, again, none of this is  
enforceable.
>
> 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.

OASIS can't mandate anything of the sort.

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

I agree. --- when someone gets around to writing it, it would be very  
useful
>
> Question - once we have this document, don't we have to go back  
> through and validate that the existing specs satisfy the criteria?

yes
>
>> c.      An adapted version of the SCA Assembly Test Suite for  
>> testing the implementation type is created and is made  
>> publiclyavailable to its prospective development community.
>>
> Again, 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.

+1

cheers,
   jeff m
>
>> 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?
>
>> 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.
>
>
>
>
>>   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?
>
> -Eric.
>
>>
>>
>> ---------------------------------------------------------------------
>> 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

--
Jeff Mischkinsky			          		jeff.mischkinsky@oracle.com
Sr. Director, Oracle Fusion Middleware 				+1(650)506-1975
	and Web Services Standards           			500 Oracle Parkway, M/S 2OP9
Oracle								Redwood Shores, CA 94065