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] A New SCA Testing TC?


AND, it should contain a specific list of those features (and tests)  
that could not map due to the nature of the implementation language if  
any.
-bob
On Jul 17, 2009, at 10:09 AM, Martin Chapman wrote:

> Each language has to have a mapping to SCA so b) requires public  
> documentation of how this is done. I think having this will be
> important to understanding the tests, and aid verification.
>
> Martin.
>
>> -----Original Message-----
>> From: ashok malhotra [mailto:ashok.malhotra@oracle.com]
>> Sent: 17 July 2009 14:58
>> To: Martin Chapman
>> Cc: 'OASIS Assembly'
>> Subject: Re: [sca-assembly] A New SCA Testing TC?
>>
>> Martin:
>> Why do we need b) ?
>>
>> If they show the test suite and say they pass all the language- 
>> dependent
>> and language-independent tests, isn't that sufficient?
>> All the best, Ashok
>>
>>
>> Martin Chapman wrote:
>>>
>>> On the MS/Siemens issue, how about we change the conformance
>>> requirements in the assembly spec to the effect of a) and b) in your
>>> email.
>>>
>>> Currently we say in Section 13.2
>>>
>>> .
>>>
>>> 3.The implementation MUST support and comply with at least one of  
>>> the
>>> OpenCSA Member Section adopted implementation types.
>>>
>>> How about replacing this with (something like):
>>>
>>> 3. The implementation MUST support and comply with a publically
>>> available implementation type. A publically available implementation
>>> type MUST:
>>>
>>> a) Have a publicly available version of the test suite written in  
>>> the
>>> implementation type, available for any party to download, validate  
>>> and
>>> execute
>>>
>>> b) Have a publicly available document(s) describing the  
>>> implementation
>>> type, which, at a minimum, describes the mapping from implementation
>>> type artifacts to the componentType when the implementation artifact
>>> is used as the implementation of an SCA Component.
>>>
>>> Note that OpenSCA Member Section adopted implementation types  
>>> fulfill
>>> these requirements.
>>>
>>> *From:* Mike Edwards [mailto:mike_edwards@uk.ibm.com]
>>> *Sent:* 17 July 2009 10:01
>>> *To:* OASIS Assembly
>>> *Subject:* [sca-assembly] A New SCA Testing TC?
>>>
>>>
>>> Folks,
>>>
>>> Bob's points below really go into the area of the responses that we
>>> owe Microsoft and Siemens
>>> relating to their public review comments on the Assembly spec.
>>>
>>> It is my belief that the Assembly tests have been structured in  
>>> such a
>>> way that they are adaptable
>>> to a any new future implementation type, although I agree that the
>>> TestCases document needs to
>>> be more explicit and normative about which parts of the testcases  
>>> can
>>> be changed and what
>>> changes are allowed.
>>>
>>> The problem remains however, about how we can ensure that a vendor
>>> implementing a new
>>> implementation type and wanting to claim conformance for their  
>>> runtime
>>> using that implementation
>>> type satisfies 2 key requirements:
>>>
>>> a) Have a publicly available version of the test suite written in  
>>> the
>>> new implementation type,
>>> which can be used by all and which would be subject to scrutiny for
>>> the validity of the translation
>>> of the testcases.
>>>
>>> b) Have a publicly available document describing the new
>>> implementation type which at a
>>> minimum describes the mapping from implementation type artifacts to
>>> the componentType
>>> when the implementation artifact is used as the implementation of an
>>> SCA Component.
>>>
>>>
>>> So far, the only route we have of guaranteeing both of these
>>> requirements is to require that
>>> the new implementation language is described by a specification
>>> developed under the
>>> aegis of an OASIS TC.
>>>
>>> I am interested to hear if there some alternatives available which
>>> will provide these requirements
>>> while allowing some alternative approach to the development and
>>> publishing of the materials.
>>>
>>>
>>>
>>> I don't think that a "Testing TC" affects these questions much at  
>>> all.
>>> I tend to agree with Bob that
>>> the value of a separate Testing TC is questionable and there remains
>>> an issue relating to the
>>> implementation type specific tests that an impl language TC may want
>>> to require as part of the
>>> conformance requirements for their spec. To me, these tests seem to
>>> naturally belong to the
>>> language TC itself. Having a separate TC with different membership
>>> seems like a recipe for
>>> conflict and/or missing testcases....
>>>
>>>
>>> Yours, Mike.
>>>
>>> Strategist - Emerging Technologies, SCA & SDO.
>>> Co Chair OASIS SCA Assembly TC.
>>> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great  
>>> Britain.
>>> Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
>>> Email: mike_edwards@uk.ibm.com
>>>
>>> From:
>>>
>>>
>>>
>>> Bob Freund <bob.freund@hitachisoftware.com>
>>>
>>> To:
>>>
>>>
>>>
>>> ashok.malhotra@oracle.com
>>>
>>> Cc:
>>>
>>>
>>>
>>> OASIS Assembly Test <sca-assembly-testing@lists.oasis-open.org>,  
>>> OASIS
>>> Policy <sca-policy@lists.oasis-open.org>, OASIS Bindings
>>> <sca-bindings@lists.oasis-open.org>, OASIS Java
>>> <sca-j@lists.oasis-open.org>, OASIS BPEL
>>> <sca-bpel@lists.oasis-open.org>, OASIS CPP
>>> <sca-c-cpp@lists.oasis-open.org>
>>>
>>> Date:
>>>
>>>
>>>
>>> 16/07/2009 22:03
>>>
>>> Subject:
>>>
>>>
>>>
>>> Re: [sca-policy] A New SCA Testing TC?
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> Ashok,
>>> I am somewhat sympathetic to the argument that it ought to be  
>>> possible
>>> for a new language to be brought in to the family, but I am  
>>> concerned
>>> about creating a centralized testing TC.
>>> One main reason is that it is unclear how long such a TC would be
>>> staffed or its members remain interested. A new language could come
>>> along years from now.
>>> IMO it would be better to describe the language interface tests in a
>>> language independent manner so that they could be implemented in
>>> whatever language as may arise in the future.
>>> The problem is the determination of the correct implementation of
>>> those "meta" tests. Perhaps there is some technical solution, but it
>>> escapes my limited imagination.
>>> an alternate approach might be that the implementors might self-
>>> certify and be required to publish the tests used as well as the
>>> results before being able to claim conformance. The customer's might
>>> them be able to judge for themselves the degree of rigor used and  
>>> thus
>>> the quality of the self-certification.
>>> -bob
>>>
>>> On Jul 15, 2009, at 4:42 PM, ashok malhotra wrote:
>>>
>>>> If you have been following the Assembly Testing work, you know that
>>>> the Assembly Test Cases are written in Java.
>>>> Mike is now preparing a BPEL version.
>>>>
>>>> Clearly, the Java test cases test the Java C&I to some extent and
>>>> Bryan has raised an issue that asks whether the Assembly and Java
>>>> tests should be more cleanly separated, but there are
>>>> complications. The Assembly tests need some C&I to test and some
>>>> duplication cannot be prevented. Also, if the Assembly tests and
>>>> the language tests were separated, then who adjudicate differences
>>>> of opinion and duplication? Further, if the Assembly tests were
>>>> shorn of any language C&I, someone could come along, pass only the
>>>> Assembly, Policy and Bindings tests and claim SCA compliance.
>>>>
>>>> So, I'm suggesting we consider forming a new TC that would be
>>>> responsible for all SCA Testing.
>>>> Before you go "Aaargh! Not another TC!", please consider the
>>>> advantages:
>>>>
>>>> 1. Bryan's issue would be closed as there would be only a single TC
>>>> and it would write and manage all the tests, some
>>>> of which would, of course, cover Assembly and one or more language
>>>> C&Is. In fact, thinking about it, many of the tests
>>>> would cover some Assembly features, some Policy, a binding and some
>>>> C&I.
>>>>
>>>> 2.. If all the tests were in a single TC there would be no need for
>>>> someone else to settle disputes.
>>>>
>>>> 3. If an outside party were to come and claim SCA compliance, the
>>>> Testing TC would have the authority to vet their
>>>> tests and say 'yay' or 'nay'. Or to enforce which tests they should
>>>> run.
>>>>
>>>> What do people think?
>>>> --
>>>> All the best, Ashok
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> /Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with
>>> number 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire  
>>> PO6
>>> 3AU/
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>

smime.p7s



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