[7:57] Sanjay: Agenda:
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 Mar 26, 2009 minutes
http://lists.oasis-open.org/archives/sca-bpel/200903/msg00060.html
5. Action Items review
#0059 Anish - Create Test Assertions for conformance items until SBPEL2020
#0060 Khanderao - Create Test Assertions for conformance items - SBPEL2021 to SBPEL3010
6. Testing schedule
We are past the previous schedule dates. We need a new schedule.
Proposal:
Review completed Test Assertions: 4/9/09 ?
TestCases complete : 4/30/09 ?
Public review draft ready : end of spec PR (5/31/09) ?
1st Public review complete : 60 days after start (7/31/09) ?
This would have to be synced with assembly schedule as it provides the necessary testing infrastructure.
7. New issues (PR Issues)
a. Issue 30 - Schema contains ##any for
http://www.osoa.org/jira/browse/BPEL-30
8. Test assertion doc and testing
3rd draft: http://lists.oasis-open.org/archives/sca-bpel/200903/msg00056.html
9. AOB
-----------------------------------------
Scribe list:
* Kand, Khanderao (9/20/07, 1/31/08, 4/10/08, 7/10/08, 10/09/0 : 5
* Rowley, Mr Michael (9/27/07, 2/7/08, 9/11/08, 12/11/0 : Issues Editor
* van der Rijn, Danny (12/06/07, 5/22/08, 6/19/08, 7/24/08, 11/6/08, 8/1/9): 7
* Andrabi, Mr. Najeeb (10/4/7, 2/14/8, 3/27/8, 5/8/8, 9/25/8, 10/23/8, 2/26/9): 7
* Booz, Dave (10/30/08, 3/5/09): 2
* Koenig, Mr Dieter (10/25/7, 1/10/8, 3/13/8, 4/24/8, 7/31/8, 10/16/8, 2/5/9,3/12/09): 9
* Chapman, Dr Martin (9/7/07, 12/13/07, 2/28/08, 5/15/08, 2/19/9,3/19/09): 6
* Malhotra, Mr Ashok (Last scribed: 2009-03-26): 8
[8:04] Danny van der Rijn: minutes approved
[8:04] anish: Scribe: Danny van der Rijn
[8:04] anish: ScribeNick: Danny van der Rijn
[8:04] anish: Date: 2009-04-02
[8:04] anish: Chair: Sanjay Patil
[8:05] Danny van der Rijn: Actions: Neither Anish nor Khaderao had time to get to theirs. Both actions remain open
[8:05] Danny van der Rijn: Topic: Testing Schedule
[8:08] Danny van der Rijn: Proposal: Sanjay: target for first milestone (4/9) may still be achievable. Other dates would be used to trigger discussions with liason committee.
[8:10] Danny van der Rijn: Anish: Issue has been raised by Dave, and in other TCs.
[8:12] Danny van der Rijn: Michael: Isn't ##any used for forward compatibility
[8:13] Danny van der Rijn: Motion: Open issue and close with proposal in email (m:Danny, s:Najeeb)
[8:14] Danny van der Rijn: Anish: Not for UPA, for scope extensibility. If we define our attribute, we define how it's used. WRT to future version allowing use of a new attribute, this would only come into play if the SBPEL namespace weren't changed.
[8:15] Danny van der Rijn: Michael: Are we going to allow any possibility for a backward compatible change? Determination by SCA seems to be not. Who are we in BPEL to say ##otherwise?
[8:16] Danny van der Rijn: Motion carries unanimously
[8:16] Danny van der Rijn: Topic: Test assertion doc and testing
[8:17] Danny van der Rijn: Sanjay: Anish posted most current version last night, as above
[8:19] Sanjay: SBL-TA-SP01
[8:25] Danny van der Rijn: Mike: Where are the 2 attributes attached?
[8:26] Danny van der Rijn: Sanjay: Question originates in spec ambiguity.
[8:29] Sanjay: The partnerLinkType and partnerRole attributes of the partner link and the child element <sca-bpel:multiReference> of the associated multi-valued reference variable MUST be matched.
[8:30] Danny van der Rijn: Mike: An issue needs to be raised. Wording needs to be much more specific. Still don't like wording - isn't specific enough
[8:30] anish: s/partner link/<partnerLink>
[8:31] anish: The @partnerLinkType and @partnerRole attributes of the <partnerLink> and the child element <sca-bpel:multiReference> of the associated multi-valued reference variable MUST be matched.
[8:32] Danny van der Rijn: Sanjay: Agree with Mike. Need to be more clear. Need an action to open the issue
[8:32] Danny van der Rijn: Action: Sanjay to open the issue
[8:32] Michael Rowley: The partnerLinkType and partnerRole attributes of the partner link MUST be the same as the partnerLinkType and partnerRole attributes of the <sca-bpel:multiReference> child element of the variable named by the @multiRefFrom attribute of the partner link.
[8:33] anish: The partnerLinkType and partnerRole attributes of the <partnerLink> MUST be the same as the partnerLinkType and partnerRole attributes of the <sca-bpel:multiReference> child element of the variable named by the @multiRefFrom attribute of the partner link.
[8:36] Danny van der Rijn: Anish: Does the wording above seem right? Should we try to resolve this now?
[8:36] anish: it would be issue #31
[8:37] Danny van der Rijn: Sanjay: Question about last clause: "named by ..." part - is it precise enough to be spec language?
[8:37] anish: The partnerLinkType and partnerRole attributes of the <partnerLink> MUST be the same as the partnerLinkType and partnerRole attributes of the <sca-bpel:multiReference> child element of the variable named by the @multiRefFrom attribute of the <partnerLink>.
[8:37] Danny van der Rijn: Michael: Will get harder to read if we try to add variable reference semantics
[8:37] anish added more angle bracket
[8:38] anish: how about s/named/identified/
[8:39] anish: The partnerLinkType and partnerRole attributes of the <partnerLink> MUST be the same as the partnerLinkType and partnerRole attributes of the <sca-bpel:multiReference> child element of the variable whose @name value is same as the value of the @multiRefFrom attribute of the <partnerLink>.
[8:40] Michael Rowley: Title: SBPEL3011 Assertion needs to be clarified
[8:40] Michael Rowley: he assertion:
[SBPEL3011] The partnerLinkType and partnerRole attributes of the partner link and multi-valued reference variable MUST be matched.
is vague.
Proposal:
It should be changed to the following:
[SBPEL3011] The partnerLinkType and partnerRole attributes of the <partnerLink> MUST be the same as the partnerLinkType and partnerRole attributes of the <sca-bpel:multiReference> child element of the variable whose @name value is same as the value of the @multiRefFrom attribute of the <partnerLink>.
[8:41] Danny van der Rijn: Motion: To open an issue with title and body as pasted into room above (m: Michael Rowley, s: Anish)
[8:41] anish: This is issue 31
[8:41] Danny van der Rijn: Motion carries unanimously
[8:42] Danny van der Rijn: Motion: Resolve new issue according to proposal (m:Michael Rowley, s: Khanderao)
[8:42] Danny van der Rijn: Motion carries unanimously
[8:43] Danny van der Rijn: Sanjay: Back to test assertions...
[8:44] Danny van der Rijn: Action: Sanjay to reword SBL-TA-SP01 to reflect new tighter spec language
[8:44] anish i think finishing review of TAs by next week is not going to happen 
[8:44] Danny van der Rijn: On to SBL-TA-SP02
[8:47] Danny van der Rijn: Mike: Not testing a runtime anymore - you have to make a test runtime.
[8:47] Danny van der Rijn: +1
[8:48] Danny van der Rijn: Sanjay: SBL-TA-SP03
[8:56] Sanjay: Title: SBPEL3013 and SBPEL3014 use of RFC2119 'MAY' incorrectly
[8:56] Sanjay: Proposal: Use alternative wording for RFC 2119 'MAY' e.g. 'can'.
[8:57] Danny van der Rijn: Motion: Open a new issue, with title and description as typed above by Sanjay. (m: Sanjay, s: Danny)
[8:57] Danny van der Rijn: s/description/proposal/
[8:58] Danny van der Rijn: Motion carries unanimously (Issue # will tentatively be 32)
[8:58] Danny van der Rijn: Anish: AOB?
[8:59] Danny van der Rijn: Anish: Adjourned
|