From: Mike Edwards
[mailto:mike_edwards@uk.ibm.com]
Sent: Wednesday, October 14, 2009 5:33 PM
To: Konradi, Philipp
Cc: OASIS Assembly
Subject: RE: [sca-assembly] [ISSUE 149] Resolution status - and a
Directional Proposal
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: mike_edwards@uk.ibm.com
From:
|
"Konradi,
Philipp" <philipp.konradi@siemens.com>
|
To:
|
Mike
Edwards/UK/IBM@IBMGB, "OASIS Assembly"
<sca-assembly@lists.oasis-open.org>
|
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: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
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