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
>> 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
Sr. Director, Oracle Fusion Middleware +1(650)506-1975
and Web Services Standards 500 Oracle Parkway, M/S 2OP9
Oracle Redwood Shores, CA 94065
