RE: [sca-assembly] [ISSUE 149] Resolution status - and a DirectionalProposal

Philipp,

The point I'm trying to get at with
the statement you picked out is that we need that:

1) It MUST be the case that a document
exists for the Implementation Type and that a version of the Test Suite
also exists 

2) It MUST also be the case that the
Implementation Type document and the Test Suite version are "freely
available"

- the document should be available publicly
with a license that permits anyone to obtain a copy ("equivalent"
terms to

those applying to OASIS public specifications,
but not requiring the document to be published by OASIS and not requiring

it to use OASIS terms)

- the Test Suite should be available
freely - and in my thinking that would mean available from a public location
under

an accepted open source license.  Again,
does not have to be available from OASIS and we can be flexible about the

license, but what I don't want to see
is the ability for a vendor to tie the Test Suite to the purchase of a
product, or to

place restrictive terms on its availability.
 I think that the base test suite is really a piece of open source
and that this

modified implementation specific version
of the test suite is simply building on that base.  

This does NOT imply that a commercial
company has to make their SCA runtime freely available, of course - so

to actually RUN the test suite it may
well be necessary to buy a license for the runtime.  However, "the
court of public

opinion" which is what is really
being used to police the conformance here, requires that the test suite
can be

inspected freely, even without being
able to run it - for example, a company make make short cuts in its implementation

of the test suite, which should be open
to comment.

I don't know if any of this is really
going to work - how can an OASIS specification make demands of this kind
and have

any expectation that they will be honoured?
 - I suspect that we are blazing a trail into new territory here as
I am not aware

of a standards TC having made requirements
of this kind before...

All comments welcome

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:  

From:
"Konradi, Philipp" <>

To:
Mike Edwards/UK/IBM@IBMGB, "OASIS
Assembly" <>

Date:
14/10/2009 15:51

Subject:
RE: [sca-assembly] [ISSUE 149] Resolution
status - and a Directional Proposal

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

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:  

From:

"Konradi, Philipp" <>

To:

"OASIS Assembly" <>

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:

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 

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