RE: [sca-assembly] REOPEN ISSUES 132 and 149: Update to Sanjay'sProposal

["Konradi, Philipp" <philipp.konradi@siemens.com>]

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?!
In my opinion the *opposite* is the case. I see broad agreement that the conformance requirements are too strict 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