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



Folks,

A couple of comments inline...

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


Jeff Mischkinsky <jeff.mischkinsky@oracle.com> wrote on 27/04/2010 21:20:38:

> [image removed]

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

>
> Jeff Mischkinsky

>
> to:

>
> Eric Johnson

>
> 27/04/2010 21:21

>
> Cc:

>
> "Estefan, Jeff A (3100)", OASIS Assembly

>
>
> On Apr 27, 2010, at 10:06 AM, Eric Johnson wrote:
>
> > 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.
> This is along the lines of an approach i suggested several months ago  
> as a possible way forward, that the TC decided was "too hard/
> complicated" to address in the remaining 1.1 timeframe. You claim  
> conformance of your implementation type, by claiming that it  
> implements and conforms to what i would describe as the meta spec.
>    (BTW: one of the criteria i believe should be a test suite.)


Well, it did not seem to take all that much effort to create the 2 documents
that are available on the OASIS repo.  Perhaps we made the wrong evaluation
originally.

I'd be interested to know what you mean by one criterion being a test suite.
SCA Assembly has a test suite but makes no demands on other specs that they
have a separate test suite.

>
> >
> > 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 agree that this should be discussed for 1.2, but I think it is way  
> too late in the game for the 1.1 train -- especially because IMO this  
> needs to be a rigorous spec, carefully vetted, reviewed, and debugged.  
> It will take several months to do so, irrespective of the extra time  
> for public reviews, etc.
>
> One other issue I just thought of is that if the TC adopts this  
> approach, I wonder if an unintended consequence might be that there  
> are no more C&I specs adopted by OASIS. Why would I as a vendor want  
> to subject my work to review and standardization by another group when  
> i don't have to. In fact, what would prevent, say Oracle, from  
> shipping its own java or bpel implementation type and claiming  
> conformance? something to think about... since the assumption has been  
> that this would be used only for "new" languages.


The reason for the existence of the standardized Implementation Type specs
is that it gives portability for artifacts of that implementation type.
Customers who want to use "implementation.java" will likely ask for
conformance to the requirements of that spec as well as conformance to
SCA Assembly.  That pressure is what will act against Runtime providers
doing "their own" implementation.bpel (etc).

For commonly used implementation types, the driving force for specifications
formally standardized will ultimately come from customers.

I note that there is not much in our present requirements that stops Runtime
providers from building their own versions of implementation.java (etc) since
SCA Assembly only requires conformance to 1 "standard" implementation type.
The runtime can also support 1,000 other non-standard implementation types.
It is ultimately marketplace pressure that supports standards.

>
> >
> > 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.
>
> The OASIS Process Committee has been dealing with this for several  
> years. It finally completed a proposed changed to the TC Process which  
> would create a new class of documents, tentatively named Committee  
> Notes. A draft of the proposal was posted to the chairs list, i  
> believe, a while ago. Some board members strongly objected to adopting  
> it because they are opposed to CNs being subject to the (protections  
> of) the OASIS IPR Policy. The current status is that board decided to  
> defer voting pending further deliberations.
>
> So i'm afraid there is not much mary or other oasis staff members can  
> do with it.


Agreed.  

Either we create new specification docs or we extend some of the existing ones.

>
> cheers,
>    jeff
>
>
> >
> > -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/37466/sca-assembly-1.1-impl-type-documentation-wd02.odt
> >>
http://www.oasis-open.org/apps/org/workgroup/sca-assembly/
> download.php/37467/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
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
>






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]