RE: [sca-assembly] [ISSUE 149] Resolution status

I’m of course in favor of Approach B :-) Approach A is too restrictive IMHO for the reason’s mentioned in JIRA issue 149.

> A difficulty with this approach is having control over the availability of these necessary document and testcase artifacts - legally, how can it be controlled?

Actually I’m not sure whether we have really an additional difficulty here. I mean, is it really important that *OASIS* is in control over the availability of these documents?

I think that the *users* of an SCA Runtime validate its conformance to the spec and execute the Test Suite if they want to (when suspecting deviation for example). Whether they got the impl. type spec + impl. type specific part of test cases from OASIS or from another publicly available place is not essential. But maybe I’m missing something?!

Yours,

Philipp

From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Tuesday, October 13, 2009 5:02 PM
To: Konradi, Philipp; OASIS Assembly
Subject: Re: [sca-assembly] [ISSUE 149] Resolution status - and a Directional Proposal

Folks,

It is time for the Assembly TC to move to resolve issues 149 and 132.

Both of these issues relate to the implementation type support required by the Assembly specification.

I believe that there are two alternative directions in which these issues can be resolved, and we should start
by making a directional resolution which decides between them:

Approach A.

Stick with the requirement that an SCA runtime that claims conformance to the SCA Assembly specification must implement
at least one SCA implementation type that is formally standardized by an OASIS TC, and that the SCA runtime must pass
the version of the SCA Assembly Test Suite that uses that implementation type as its base.

The version of the SCA Assembly Test Suite for any implementation type will be freely available from OASIS.

The implementation type will have a formal document that describes its relationship to the SCA Assembly model and this
will be published from OASIS.

Approach B.

Relax the requirement for support of implementation types that an SCA runtime must support when it claims conformance to the SCA Assembly specification.

Change to a model where the requirement is that the SCA runtime must support an implementation type that meets the following requirements:

1. There is a publicly available document that describes the implementation type and which relates aspects of the implementation type artifact(s) to the SCA Assembly
specification - in particular, it defines the component type of an arbitrary implementation type artifact and it describes how an implementation type artifact is
instantiated when it forms the implementation of a component within an SCA composite.

2. There is a publicly available version of the SCA Assembly test suite that uses the implementation type for its low level implementation artifacts

This approach will requires a document that describes what is required for items 1) and 2).

A difficulty with this approach is having control over the availability of these necessary document and testcase artifacts - legally, how can it be controlled?

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:	"Konradi, Philipp" <philipp.konradi@siemens.com>
To:	"OASIS Assembly" <sca-assembly@lists.oasis-open.org>
Date:	05/10/2009 17:11
Subject:	[sca-assembly] [ISSUE 149] Resolution status?

Hi all,

some discussions related to Siemens concerns on impl. language independence (http://www.osoa.org/jira/browse/ASSEMBLY-149) took already place and I was wondering about the current status.

Martin proposed in [1] to relax conformance requirements to some extent. This proposal seemed to receive broad acceptance on the mailing list.

Further Jim and Mike were discussing a solution proposal to increase language-independence in the Assembly test suite complementing Martin’s proposal nicely from the testing perspective.

Can somebody tell about the status here? Mike? What further work is required to proceed it to an official proposal so that concerns raised in http://www.osoa.org/jira/browse/ASSEMBLY-149 can finally be resolved?

I’d be glad to help here out.

Regards,

Philipp

[1] http://lists.oasis-open.org/archives/sca-assembly/200907/msg00045.html

With best regards,

Philipp Konradi

Siemens AG

Corporate Technology

CT SE 22

Otto-Hahn-Ring 6

81739 Munich, Germany

Tel.: +49 (89) 636-53802

Fax: +49 (89) 636-45450

mailto:philipp.konradi@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Wolfgang Dehen, Heinrich Hiesinger, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

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

sca-assembly message