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] Concerns raised by Siemens



Jim,

I'd like to address the points you make - but I am going to separate this from the points made by Philipp, which I will discuss in a separate email.

Your point about these issues being brought up at the F2F meeting.
The agenda for the F2F included two sections on "Assembly Specification V1.1 completion", which included "consideration of remaining issues and work items"
- I agree that this did not list all of the issues individually, but the meaning of this is clear in my mind - ie that all issues open against the 1.1 specification would be
discussed.  And that includes the issues which dealt with the public comments from both Siemens and from Microsoft.

This agenda was also discussed at previous TC conference calls, and the objective of closing out ALL remaining issues at the F2F was made clear.

It is unfortunate that you were not able to be present during the discussion.

Turning to your numbered points:

1. Including the interested parties.

I believe that there has been quite a lot of discussion of these issues on the Assembly mailing list - over the past months.
On a personal level, I posted several emails, where I attempted to summarize the main points of debate and the form that
any alternative solution would have to take.  The sorts of problems that these alternative solutions have were also discussed
both on the email list and during various TC calls.

As for comments made by TC members during the F2F - anyone is free to express their views and I would not subscribe to any
form of censorship.

2. There is a satisfactory solution (Sanjay's)

Well, you may think that it is satisfactory, but that was not the consensus of opinion expressed at the F2F.  I urge you to make your
case to the TC that Sanjay's approach is satisfactory.

However, the consensus view was that it is difficult if not impossible to lay down rules that have any meaning once those rules involve
work done outside OASIS.  I think the view is that there must be 2 items in place to give any meaning to "conformance" when dealing
with a runtime that only implements implementation type(s) not standardized under OASIS

  a) A specification or document that describes the implementation type and its relationship to the Assembly model, in particular the
      componentType derivation must be spelled out in detail.


  b) A version of the test suite using the implementation type must be run against the runtime

We have not been able to establish a satisfactory way of assuring that both of these items are in place - and please note that this
is not about the technical format of the two items, but is about how it is possible to require both that they exist and that they are
open to inspection.
For example, the use of "copyleft" styles of license for the test suite to ensure that the test suite for the new implementation type is
available has not proved acceptable to numerous TC members (that group includes myself).

If someone can suggest a satisfactory approach to these two items, I am sure that the TC will be only too happy to listen - however,
I think it is a tough problem, with potential legal aspects that may require OASIS board approval.

3. Provide a Public Response

Yes, we agreed to do this and Martin and myself were given an action item to prepare the responses.
Christmas and other work commitments have slowed things up, but you will see that the proposed responses have been posted to the
Assembly mailing list today, prior to discussion and approval (hopefully) at the next TC meeting.



I agree with your desire that SCA should be as open as possible.  On the other hand, the question of "conformance" is an important one
since it helps provide both portability and interoperability between SCA runtimes of different vendors, one of the major goals of bringing
the SCA specifications for standardization in the first place.  We need to find a way of avoiding tossing the baby out with the bathwater
here.  It is clear that anyone can produce an SCA runtime which provides implementation types which are not those standardized at
OASIS - SCA is inherently extensible.  The problem concerns what it means to be "conforming to the SCA Assembly specification" -
what meaning and assurance can be given to such a statement.

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: Jim Marino <jim.marino@gmail.com>
To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date: 18/12/2009 16:41
Subject: Re: [sca-assembly] Concerns raised by Siemens





Hi,

I would like to second Philipp's comments and offer whatever help it takes to implement Sanjay's proposal. Making SCA a more open standard by providing a way to assert conformance using proprietary implementation languages will help with SCA adoption which up to this point has been a bit slow.

I would also like to comment that I was very surprised to find out this issue was brought up late during the face-to-face, without any forewarning. Unfortunately, due to time zone constraints, I wasn't present during the discussion. In my opinion, it would have been much more productive to have:

1. Made more of an effort to include interested parties by continuing the original discussion on the mailing list or calling it out as an explicit agenda item for the face-to-face. We should be aiming at making SCA inclusive. For example, the following comment taken from the F2F meeting minutes over ASSEMBLY-132 and ASSEMBLY-149 does not appear to be in that spirit:

"Essentially it seems that current proposals allow companies to claim conformance to standards without going through the standards process ...MS [Microsoft] could always do a BPEL implementation but it is their problem not ours"

2. Characterized the issue more accurately. The following was stated during the meeting minutes:

"We've actually spent a lot of time on this and been unable to find a satisfactory solution...the issue is delaying the spec and we shouldn't spend more time on this for 1.1"

Actually, there is a proposal (Sanjay's) that does provide a satisfactory solution. In addition, I have spent a significant amount of time with Mike Edwards reviewing the test cases and it is our opinion that the existing structure does provide the ability to verify conformance against proprietary languages. As Philipp said, claiming there is not enough time is a stretch given the issue was raised back in June. If time is as issue, why is significant work being done on the 1.2 specs (e.g. eventing) prior to 1.1 being complete?

3. Provided an official response/explanation as to why the issue was closed. I have only seen the meeting minutes and am not aware of any official response being sent.

I believe these public comments were made in good faith and with the desire to make SCA more open. It would be better if we made an attempt to work directly with the companies that raised these issues and others during the public comment period. Why not engage them to work together on a solution that is satisfactory to everyone?

Jim








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








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