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

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

oh, and how will you ever get anyone onto 1.2 if the requirements are  


> 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:
> 7466/sca-assembly-1.1-impl-type-documentation-wd02.odt
> 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
> Shores, CA 94065

Jeff Mischkinsky
Sr. Director, Oracle Fusion Middleware
	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:

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