[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] REOPEN ISSUES 132 and 149: Update to Sanjay's Proposal
On Apr 29, 2010, at 4:45 AM, Konradi, Philipp wrote:
> Hi,
>
> I agree with Sanjay and especially one of his last statements:
>> By lowering the bar and inviting more entrants in the game now, I
>> think
>> we will be making the value proposition of the SCA standard more
>> attractive to the user community. I guess vendors will most likely
>> jump
>> through any hoops such as adopting a new version with tighter
>> requirements because their customers are asking them to do so (and
>> not
>> because a certain TC is demanding something).
>
> Jeff, I fail to see why Sanjay's proposal is supposed to go into the
> wrong direction?!
Because following that path will make a product that was previously
conformant, non-conformant.
So it creates an automatic constituency that would be opposed to
adding requirements.
It is always easier to relax conformance requirements than to
strengthen them.
> In my opinion the *opposite* is the case. I see broad agreement that
> the conformance requirements are too strict
i don't see broad support - i see disagreement
-jeff
> and should be relaxed in future or in other words focus on SCA
> assembly model and don't require support for specific implementation
> types. The only question now from my point of view is whether
> certain form/ requirements on a document, describing how a
> proprietary implementation type maps into SCA's assembly model and
> provided by an SCA runtime implementer, should be defined and if how
> would they look like. The same for the test suite and license.
>
> So I see broad agreement on *what* we want to achieve and
> discussions on the form, the *how*.
> Sanjay's last proposal is just to do the first step without trying
> to define every bit of *how* upfront, see which practices proved
> themselves and were well received by the community and only in the
> next step set the requirements details in stone.
> This sounds like a fine evolutionary approach to me. Definitely
> better than do nothing and provide something in 2-3 years.
>
> In addition to what Sanjay described I'd also like the idea to
> release the documents started by Jeff Estefan / Mike Edwards as a
> recommendation / guideline in the first step.
>
> Another question before we continue the compromise discussions: Did
> somebody had a chance to look through the documents submitted by
> Jeff Estefan / Mike Edwards?
> These metaspecs were very probably extracted on the basis of
> existing SCA specs & test suites, so I'd suppose those comply
> already with the metaspecs without requiring much effort to make
> them do so. This would minimize extra work and delay in the 1.1 cycle.
>
> Just my 2c,
> Philipp
>
>> -----Original Message-----
>> From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
>> Sent: Wednesday, April 28, 2010 10:57 PM
>> To: Jeff Mischkinsky
>> Cc: Martin Chapman; Eric Johnson; Estefan, Jeff A (3100); OASIS
>> Assembly
>> Subject: RE: [sca-assembly] REOPEN ISSUES 132 and 149: Update to
>> Sanjay's
>> Proposal
>>
>>
>> Hi Jeff,
>>
>> - What is wrong in starting with a baseline set of requirements
>> that are
>> intentionally less stringent and tightening them later after ensuring
>> some traction and experience with the technology. I think it is a
>> good
>> compromise for us (the SCA TCs) to define a baseline conformance
>> (e.g.
>> in terms of adherence to the language-neutral assembly and policy
>> specs)
>> in 1.1 and let the market-demand drive the next set of conformance
>> requirements (e.g. requirements on the language and binding specs).
>>
>> - It is not uncommon to tighten requirements in subsequent
>> revisions of
>> an initial body of work. What was all the profiling work under WS-I
>> about? Now don't say that ws-i did not work out and the profiling
>> model
>> itself is invalid. Sure, it wasn't a lot of fun but I am not sure why
>> you would conclude that it is impossible to tighten requirements
>> later.
>> In fact, it might be the right practical move in many cases.
>>
>> - If we go by your approach of first imposing tight requirements and
>> relaxing them later, please explain how the proposal would look
>> like? By
>> closing 132/149 with no action, we are essentially closing the door
>> for
>> other implementation types to implement and claim conformance with
>> SCA
>> 1.1. There is just no scope for tightening or loosening the
>> requirements
>> in this scenario.
>>
>> By lowering the bar and inviting more entrants in the game now, I
>> think
>> we will be making the value proposition of the SCA standard more
>> attractive to the user community. I guess vendors will most likely
>> jump
>> through any hoops such as adopting a new version with tighter
>> requirements because their customers are asking them to do so (and
>> not
>> because a certain TC is demanding something).
>>
>> Are we worrying too much about how a certain vendor(s) may abuse the
>> conformance requirements as opposed to focusing more on how the
>> technology can be made more attractive for the user community (by
>> inviting broader vendor support)?
>>
>> Best wishes,
>> Sanjay
>>
>> -----Original Message-----
>> From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com]
>> Sent: Wednesday, April 28, 2010 11:23 AM
>> To: Patil, Sanjay
>> Cc: Martin Chapman; Eric Johnson; Estefan, Jeff A (3100); OASIS
>> Assembly
>> Subject: Re: [sca-assembly] REOPEN ISSUES 132 and 149: Update to
>> Sanjay's Proposal
>>
>>
>> On Apr 28, 2010, at 9:20 AM, Patil, Sanjay wrote:
>>
>>>
>>> The 132 and 149 issues have been repeatedly raised against 1.1. As I
>>> understand the essence of these issues is to point out that the
>>> current
>>> conformance requirements are unnecessarily prohibitive for
>>> implementing
>>> and claiming conformance with the SCA standard, under certain (quite
>>> valid, I believe) circumstances. I think it is in the interest of
>>> the
>>> community supporting the SCA standard to invite a broader set of
>>> implementations (let us face it - we are having hard time to meet
>>> our
>>> own exit criteria of having two conformant implementations!). I
>>> don't
>>> think that the risk of opening the door and allowing others who are
>>> prepared to implement only a subset of the specifications to also
>>> claim
>>> conformance is that high (at least not to the extent that would
>>> justify
>>> closing down 1.1 with strict conformance requirements).
>>>
>>> If we are concerned about the potential delay to the 1.1 schedule
>>> for
>>> resolving the issue in an appropriate manner (by standardizing the
>>> precise requirements on other implementation types, their test
>>> suites,
>>> restructuring the current standard C&I specifications, etc), how
>>> about
>>> we do the following :-
>>> a> Relax the requirements in 1.1 so that other implementation types
>>> can
>>> also claim conformance (on the lines of my original proposal [1])
>>> b> Promote adoption of SCA 1.1 in the industry - gain some practical
>>> input on the standard, conformance requirements, etc, from the user
>>> community
>>> c> Continue working on a cleaner and better solution for the
>>> conformance
>>> requirements in 1.2 (with the modified proposal along with the
>>> attachment documents submitted by Jeff Estefan [2] as the starting
>>> point)
>>
>> I don't think this is a compromise.
>>
>> The problem with this approach is that it goes in the wrong
>> direction...
>>
>> It is always possible to relax a requirement, but it is virtually
>> impossible in the real world to tighten a requirement because you
>> invalidate existing things that previously were conformant.
>>
>> So from my POV this proposal gives us is the worst of all possible
>> worlds.
>>
>> oh, and how will you ever get anyone onto 1.2 if the requirements are
>> stricter?
>>
>> cheers,
>> jeff
>>
>>>
>>>
>>> Best wishes,
>>> Sanjay
>>>
>>> [1]
>>> http://lists.oasis-open.org/archives/sca-assembly/200910/msg00047.html
>>> [2]
>>> http://lists.oasis-open.org/archives/sca-assembly/201004/msg00065.html
>>>
>>>
>>> -----Original Message-----
>>> From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com]
>>> Sent: Tuesday, April 27, 2010 1:35 PM
>>> To: Patil, Sanjay
>>> Cc: Martin Chapman; Eric Johnson; Estefan, Jeff A (3100); OASIS
>>> Assembly
>>> Subject: Re: [sca-assembly] REOPEN ISSUES 132 and 149: Update to
>>> Sanjay's Proposal
>>>
>>>
>>> On Apr 27, 2010, at 11:22 AM, Patil, Sanjay wrote:
>>>
>>>>
>>>> I also agree that these should be metaspecs and our own C&I
>>>> specifications (and the associated test suites) should be their
>>>> first instances.
>>> +1 (assuming we undertake this work)
>>>
>>>> Does this mean we will have to reformat the existing C&I specs?
>>>
>>> I would hope not, but i guess it would depend upon the final form of
>>> the new metaspec. BTW: i would hope that having to reformat the
>>> existing C&I specs would not be used as an argument for doing
>>> something quick and dirty in formulating the metaspec simply because
>>> it would delay 1.1 too much if we did.
>>>
>>>> Does this mean we are signing up for a lot of new work?
>>>
>>> yes. I don't see it could possibly be otherwise - not if we want
>>> to do
>>> a proper job.
>>>
>>>> I guess these are some good questions. The good news is that we
>>>> have
>>>> some drafts for the metaspecs to look at and do some practical
>>>> evaluation of the work involved, its value, etc. I don't think
>>>> simply postponing the resolution to 1.2 on the grounds of too-
>>>> much-
>>>> work-not-enough-time is a good idea. IMHO, we should reopen the
>>>> issue (against 1.1) and get some real data in front of the TC
>>>> before
>>>> deciding the final fate of this issue. Otherwise we may end up
>>>> wasting a lot of time on several meta-discussions!
>>>
>>> I do agree that if we don't vote yes/no for re-opening against 1.1
>>> at
>>> the next meeting we will be wasting (even) more time on meta-
>>> discussions.
>>>
>>> I don't follow your conclusion that why discussing this in the 1.2
>>> timeframe would end up wasting a lot of time.
>>>
>>> cheers,
>>> jeff
>>>
>>>>
>>>> From: Martin Chapman [mailto:MARTIN.CHAPMAN@oracle.com]
>>>> Sent: Tuesday, April 27, 2010 10:53 AM
>>>> To: Eric Johnson; Estefan, Jeff A (3100)
>>>> Cc: OASIS Assembly
>>>> Subject: RE: [sca-assembly] REOPEN ISSUES 132 and 149: Update to
>>>> Sanjay's Proposal
>>>>
>>>> Not the Magna Carta? Now that sounds like Monty Python Spec text.
>>>>
>>>> As some may know the Board has been trying to propose a different
>>>> document track to cover non specs.
>>>> Unfortunately the ugly IPR issue seems to be getting in the way -
>>>> I've personally been on this case for almost 4 years now!
>>>>
>>>> FWIW I tend to agree with Eric, that these documents should be
>>>> meta-
>>>> specs, and as such will not really fall under this new category.
>>>>
>>>> Martin.
>>>>
>>>> From: Eric Johnson [mailto:eric@tibco.com]
>>>> Sent: 27 April 2010 18:06
>>>> To: Estefan, Jeff A (3100)
>>>> Cc: OASIS Assembly
>>>> Subject: Re: [sca-assembly] REOPEN ISSUES 132 and 149: Update to
>>>> Sanjay's Proposal
>>>>
>>>> For the two documents in question to be part of the conformance
>>>> criteria, calling them "templates" seems insufficient.
>>>>
>>>> I expect, rather, that we would treat these documents as "specs
>>>> about specs". That is, they should define what an implementation
>>>> specification MUST include, what it SHOULD include, and what it
>>>> MUST
>>>> NOT include (although I'm puzzling over what appropriately fits
>>>> into
>>>> the last category - "MUST NOT include the text of the Magna
>>>> Carta."? ). Only when a spec satisfies those criteria can someone
>>>> then turn around and claim that their implementation type is
>>>> conforming.
>>>>
>>>> Of course, as we discussed on the call today, it is really up to
>>>> the
>>>> TC to decide how we approach this problem, but that's my take.
>>>> That's why I prefer opening new issues against 1.2.
>>>>
>>>> I still think it is useful to talk to Mary or other OASIS staff to
>>>> see if this question has arisen before, and how it has been dealt
>>>> with.
>>>>
>>>> -Eric.
>>>>
>>>> On 04/27/2010 09:34 AM, Estefan, Jeff A (3100) wrote:
>>>> Mike,
>>>>
>>>> As mentioned on today's call, we'll need to ask the assistance of
>>>> Mary and perhaps other members of the OASIS staff about this topic,
>>>> but I do not see how these templates would need to be elevated to
>>>> formal OASIS Specification status because unlike the SCA Assembly
>>>> Model specification, which truly is an OASIS spec as it contains
>>>> "specification" language, these proposed documents contain
>>>> requirements language (in the form of templates) that are intended
>>>> to assist the user community with verifying an SCA Runtime's
>>>> conformance with a SCA Assembly Model specification.
>>>>
>>>> Looking over the various OASIS document templates
>>> (http://docs.oasis-open.org/templates/
>>>> ), I do not see on in place for such a technical work product.
>>>>
>>>> Raising these documents to full Specification level will most
>>>> certainly impede our progress on ratifying the SCA Assembly Model
>>>> v1.1 spec and I hope that is not the case, but we certainly need to
>>>> find out sooner rather than later.
>>>>
>>>> Would you like me to reach out to Mary and the OASIS staff about
>>>> this or would you and/or Martin as TC co-chairs prefer to
>>>> initiative
>>>> the question? Just let me know.
>>>>
>>>> Cheers...
>>>>
>>>> - Jeff E.
>>>>
>>>> From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
>>>> Sent: Monday, April 26, 2010 11:25 PM
>>>> To: OASIS Assembly
>>>> Subject: Re: [sca-assembly] REOPEN ISSUES 132 and 149: Update to
>>>> Sanjay's Proposal
>>>>
>>>>
>>>> Folks,
>>>>
>>>> Since some comments on this thread indicated that some people did
>>>> not see that there were a pair of
>>>> documents attached to the original email that started the thread, I
>>>> have assumed that there have been
>>>> some transmission problems and I have posted copies of the
>>>> documents
>>>> into the OASIS web site.
>>>>
>>>> They can be accessed here:
>>>>
>>>>
>>>
>> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/3
>>> 7466/sca-assembly-1.1-impl-type-documentation-wd02.odt
>>>>
>>>
>> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/3
>>> 7467/sca-assembly-1.1-testsuite-adaptation-wd02.odt
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Jeff Mischkinsky
>>> jeff.mischkinsky@oracle.com
>>> Sr. Director, Oracle Fusion Middleware
>>> +1(650)506-1975
>>> and Web Services Standards 500
>>> Oracle Parkway, M/S 2OP9
>>> Oracle
>> Redwood
>>> Shores, CA 94065
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Jeff Mischkinsky
>> jeff.mischkinsky@oracle.com
>> Sr. Director, Oracle Fusion Middleware
>> +1(650)506-1975
>> and Web Services Standards 500
>> Oracle Parkway, M/S 2OP9
>> Oracle
>>
>> Redwood
>> Shores, CA 94065
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> ---------------------------------------------------------------------
> 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
>
--
Jeff Mischkinsky jeff.mischkinsky@oracle.com
Sr. Director, Oracle Fusion Middleware +1(650)506-1975
and Web Services Standards 500 Oracle Parkway, M/S 2OP9
Oracle Redwood Shores, CA 94065
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]