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.