Re: [sca-assembly] REOPEN ISSUES 132 and 149: Update to Sanjay's Proposal

[Jeff Mischkinsky <jeff.mischkinsky@oracle.com>]

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