[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [sca-bpel] raw chat log 26th feb 09
anonymous morphed into anish Room information was updated by: anish Dial-in: 1-888-967-2253 +1-650-607-2253 +61-2-8817-6100 +44-118-924-9000
Meeting ID: 877770 Meeting password: SCABPEL (7222735) anish: 1. Roll Call http://www.oasis-open.org/apps/org/workgroup/sca-bpel/members/roster.php
2. Appointment of scribe Scribe list attached below
3. Agenda bashing
4. Approval of Feb 19, 2009 minutes http://lists.oasis-open.org/archives/sca-bpel/200902/msg00024.html
5. Action Items review a. Anish to send a draft of the test assertion doc
6. SCA BPEL schedule reminder http://lists.oasis-open.org/archives/sca-bpel/200901/msg00016.html and http://lists.oasis-open.org/archives/sca-bpel/200901/msg00018.html
Specs - PR draft ready: March 5th PR vote: March 12th
Testing - Test Assertions complete 27/02/2009 TestCases complete 27/03/2009 Public review draft ready 17/04/2009 1st Public review complete 26/06/2009
7. Opening of New Issues No new issues
8. Issue 28 - http://osoa.org/jira/browse/BPEL-28 Conversational interface support Proposal in JIRA
9. Issue 27 - http://osoa.org/jira/browse/BPEL-27 Complete the conformance section Proposal at http://lists.oasis-open.org/archives/sca-bpel/200902/msg00003.html
10. Getting PRD ready What is the plan for getting the PRD ready by March 5th? What needs to change wrt the spec? Plan from the editors to deliver the PRD by March 5th.
11. Test assertion doc and testing
12. AOB Please change your name from 'anonymous' using the Settings button anonymous morphed into Najeeb Andrabi anish: Scribe: Najeeb Andrabi anish: ScribeNick: Najeeb Andrabi anish: Date: 2009-02-26 Dave Booz thx Najeeb, i'm going to be distracted part of the time today anish: Chair: Anish Karmarkar Najeeb Andrabi: no problem Najeeb Andrabi: Anish: Testing assertions needs to be completed by tomorrow Michael Rowley is now on the call. Najeeb Andrabi: Agenda approved. Mike Edwards: that was a good squeak Najeeb Andrabi: Feb 19th meeting minutes approved. anish: http://lists.oasis-open.org/archives/sca-bpel/200902/msg00024.html Najeeb Andrabi: Action item review Najeeb Andrabi: Anish sent first draft of test assertions. Najeeb Andrabi: Issue 28 discussion. Najeeb Andrabi: Anish: Assembly has removed support for conversational interfaces. Najeeb Andrabi: Michael Rowley: Moves to resolve the issue 28 by deleting section 2.4 and non-normative appendix section Najeeb Andrabi: Najeeb seconds Najeeb Andrabi: motion is approved. Najeeb Andrabi: Issue 27 discussion anish: Topic: issue 27 anish: http://lists.oasis-open.org/archives/sca-bpel/200902/msg00003.html anish lowered your hand anish lowered your hand Martin C: 2.The implementation MUST support every SCA BPEL extension defined in this specification, and must implement them as defined. Martin C: 2.The implementation MUST support the SCA BPEL extensions defined in Section 3, and must implement them as defined. Martin C: s/must/MUST/ Martin C: this is a rewording of point 2 of 5.2 Mike Edwards: Najeeb Andrabi: Test assertion document discussion anish: http://lists.oasis-open.org/archives/sca-bpel/200902/msg00027.html Najeeb Andrabi: Anish: Test assertions same as assembly but added extra column for comments. Mike Edwards: I think that it is meaningless anish: New Issue, title: BPEL1001 is an incorrect normative statement Mike Edwards: "For an SCA component to use a WS-BPEL process as an implementation, it uses an <implementation.bpel/> element:" Najeeb Andrabi: Michael Rowley moves that BPEL1001 is an incorrect normative statement Najeeb Andrabi: Dave Booz seconds Najeeb Andrabi: as new issue anish: This is issue 29 Martin C is ready with revised conformance text anish woo hoo Najeeb Andrabi: Dave Booz moves to resolve issue 29 by replacing text in lines 6,7 and 8 Najeeb Andrabi: Michael Rowley seconds Martin C: issue 27 proposal: http://www.oasis-open.org/apps/org/workgroup/sca-bpel/email/archives/200902/msg00029.html Najeeb Andrabi: issue 29 resolved anish: http://lists.oasis-open.org/archives/sca-bpel/200902/msg00029.html Martin C: 5 Conformance
There are two categories of artifacts that this specification defines conformance for: SCA Documents and SCA Runtimes.
5.1 SCA WS-BPEL Document.
A SCA WS-BPEL Document is a document that complies with the requirements defined by WS-BPEL[2.0] and MAY include the SCA WS-BPEL extenstions defined in Section 3. Any document using these extensions must comply with the sca-bpel schema and any other constraints defined by this specification.
5.2 SCA Runtimes
There are two conformance options defined by this specification:
1. Implementations of an SCA WS-BPEL Runtime
2. Implementations of an SCA Extended WS-BPEL Runtime.
5.2.1 SCA WS-BPEL Runtime
An implementation that claims to conform to an SCA WS-BPEL Runtime MUST meet the following conditions:
1. The implementation MUST meet all the conformance requirements defined by the SCA Assembly Model Specification [Assembly] i.e. it MUST be a conforming SCA Runtime.
2. The implementation MUST be a compliant WS-BPEL Processor as defined in [WS-BPEL 2.0]. It must accept and process WS-BPEL 2.0 process descriptions in a manner defined by WS-BPEL 2.0.
3. The SCA BPEL extensions defined in this specification MUST be treated as WS-BPEL 2.0 extensions. WS-BPEL process descriptions containing the SCA BPEL extensions MAY be rejected.
4. With the exception of the SCA BPEL extensions, the implementation MUST comply with all the normative statements in this specification (appendix ?), notably all the MUST statements have to be implemented.
5.2. 2 SCA Extended WS-BPEL Runtime
An implementation that claims to conform to an SCA Extended WS-BPEL Runtime MUST meet the following conditions:
1. The implementation MUST meet the conditions for an SCA WS-BPEL Runtime above with the exception that SCA BPEL extensions defined in this specification MUST be supported. WS-BPEL process descriptions containing the SCA BPEL extensions MUST NOT be rejected
2. The implementation MUST support the SCA BPEL extensions defined in Section 3, and MUST implement them as defined. Najeeb Andrabi: Anish: lower case must in section 5.1 Martin C: all musts must be MUST Danny van der Rijn: s/must /MUST/ Najeeb Andrabi: Mike Edwards: SCA WS-BPEL document section not required. Najeeb Andrabi: Anish: We don't need to make a distinction between runtime and tools. Najeeb Andrabi: Dave Booz: we should not be in business of creating test assertions for documents anish time chk: 12 minutes Najeeb Andrabi: Ashok: SCA policy prespective documents are valdiated all the time. Martin C notes that i have made a similar proposal in Assembly Mike Edwards: But that is NOT the same as testing the documents themselves Martin C: who said anything about testing documents Martin C: this change does not affect the normative statements in rest of the doc Sanjay: I am in another meeting so can't speak. My thinking here is that - conformance statements and test assertions could have documents as target and there be no restriction on what is actually used for testing (tools, runtime, etc) Martin C: its those that we test Najeeb Andrabi: Martin Chapman move to resolve issue 27 with the text posted with all lower must changed to MUST. Martin C: http://lists.oasis-open.org/archives/sca-bpel/200902/msg00029.html Najeeb Andrabi: Ashok seconds Dave Booz: An SCA runtime MUST reject a document that does not comply ... Dave Booz: replaces "A SCA WS-BPEL Document is a document that complies " Najeeb Andrabi: Amendment failed Najeeb Andrabi: Motion is approved with no objections. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]