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's Proposal



On Apr 24, 2010, at 6:09 AM, Jeff Mischkinsky wrote:

> 
> On Apr 23, 2010, at 5: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
>> 
>> 
> 
> [ details snipped as they are not relevant to the point i am disputing here]
> 
>> 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.
> 
> yes but ...   HOWEVER, those things that are not "open", "standard-based" and/or "non-proprietary" must NOT be able to claim that they are. I just don't see how  you can have it both ways. If you want to claim some piece of work is a "standard", then, IMO, it must be vetted, scrutinized, approved, AND controlled by a "jury of its peers", so to speak, who can independently evaluate it.
> 

Are you saying runtimes which support extensions to SCA that fall outside OASIS namespaces should be precluded from claiming conformance to the Assembly specification? That interpretation of SCA would surprise me. A core principle and design tenet of SCA is to allow for extensions. Moreover, a lot of effort in the past as well as recently has gone into making extensions *outside OASIS namespaces* possible.  If so, this view of what SCA should be runs counter to a lot of the technical work that has been undertaken to date. It also runs counter to the original goal of SCA to be applicable to as many component implementation languages as possible.

Perhaps you are saying that runtimes which *only* support component implementation language extensions to SCA that fall outside OASIS namespaces should be precluded from claiming conformance to the Assembly specification? If this is the case, my question is: Why? 

Sanjay's proposal would allow runtimes to claim SCA assembly conformance using a non-OASIS component implementation language with the standard SCA assembly model. Such a combination is fully testable and is completely in line with the spirit and design of SCA, which encourages extensions. It is also in line with industry practice where vendor products implement standards and innovate on top of them via proprietary features. For example, WebLogic has enjoyed success over the years by implementing J2EE and adding a slew of proprietary capabilities such as clustering and reliability. 

I also have to say your view of what OASIS should be doing - vetting, scrutinizing, approving, and controlling - worries me. Based on my understanding of its charter, OASIS is not in the business of creating the next Committee of Public Safety (http://en.wikipedia.org/wiki/Committee_of_Public_Safety) for standards it produces. Rather, judgement is left to the "court of public opinion," which generally has a way of working things out.

Jim

>> 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 wouldn't characterize it as moral ( not sure what morality has to do with this), nor would i agree it is a personal bias (unless you are characterizing all opinions as "personal biases").
> 
> cheers,
>  jeff
> 
> 
>> 
>> <sca-assembly-1.1-testsuite-adaptation-wd02.odt><sca-assembly-1.1-impl-type-documentation-wd02.odt>
>> ---------------------------------------------------------------------
>> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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]