[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 26, 2010, at 5:48 AM, Jim Marino wrote: > > 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? No. I am saying you don't get to claim that your extension is "standard" and that is orthogonal from conformance requirements. -jeff > 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 >> > > > --------------------------------------------------------------------- > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]