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 26, 2010, at 6:08 PM, Jeff Mischkinsky wrote:

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

I'm not sure I follow your statement above. Could you clarify? 

To clarify my interpretation of the proposal, no one is arguing to allow vendors to claim "non-standard" extensions as "standard". The proposal is to define SCA Assembly conformance in such a way as to make it valid for vendors to do so with a runtime that does not support one of the OASIS component implementation languages.  In this case the parts of the runtime that implement "SCA Assembly" would be "OASIS standard",  not the non-OASIS component implementation language. I don't see how this is any different from a runtime that implements one of the OASIS component implementation languages as well as provides its own proprietary extensions. The runtime in this case can only claim to be "standard" for the parts of the SCA specifications it follows and not the value-add extensions.



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