raw minutes for 11.08

Mark Ford: Agenda approved

 

Mark Ford: 4. Approval of Nov 1, 2007 meeting 
minutes
   Raw transcript: http://lists.oasis-open.org/archives/sca-bpel/200711/msg00024.html

 

Mark Ford: No response on approval for previous 
minutes

 

Mark Ford: Chairs will take responsibility of 
formatting raw minutes

 

Mark Ford: No objection to approving 
minutes

 

Mark Ford: 5. Action items review
   
http://www.oasis-open.org/apps/org/workgroup/sca-bpel/members/action_items.php

 

Mark Ford: a) AI #0010 Mike Edwards - Notify all 
the OpenCSA TCs about update to the Issues Process for allowing status change 
from 'Applied' to 'Resolved'

 

Mark Ford: Action Item was done by Mike 
Edwards

 

Mark Ford: b) AI #0013 Danny van der Rijn - come 
back with a rewording proposal for issue-5

 

Mark Ford: Action Item was done by Danny van der 
Rijn

 

Mark Ford: c) AI #0014 Michael Pelligrini  
propose a sentence for resolving the 2nd part of issue 11

 

Mark Ford: Action item was done by Michael 
Pelligrini

 

Mark Ford: d) AI #0015 Michael Rowley  follow 
up on the 1st part of issue 11 on email

 

Mark Ford: Michael is not on the call, leaving 
action item open

 

Mark Ford: 6. Filename and URL 
Consistency
   Steering Committee recommendation:
   
http://lists.oasis-open.org/archives/sca-bpel/200710/msg00063.html

 

Mark Ford: Summary of issue - namespace 
convention

 

Mark Ford: No discussion of issue

 

Mark Ford: Mike Edwards moves to accept 
proposal

 

Mark Ford: Mike Edwards moves to accept 
proposal

 

Mark Ford: Anish seconds

 

Mark Ford: no objections, motion 
passed

 

Mark Ford: 7. New Issues

 

Mark Ford: a> Issue 15: http://www.osoa.org/jira/browse/BPEL-15
     
TITLE: Define Conformance Targets 
     SUBMITTED BY: 
Martin Chapman
     http://lists.oasis-open.org/archives/sca-bpel/200711/msg00028.html

 

Mark Ford: Summary of issue by Martin Chapman. Use 
of RFC 2119 language within spec.

 

Mark Ford: No questions or comments

 

Mark Ford: No objections, issue 
accepted

 

Mark Ford: 8. Issue Discussion

 

Mark Ford: a) Issue 5 http://www.osoa.org/jira/browse/BPEL-5
      
TITLE: The algorithm for deciding whether a partnerLink is a service or a 
reference needs to be deterministic
      SUBMITTED 
BY: Danny van der Rijn 
      Additional 
emails:
      http://lists.oasis-open.org/archives/sca-bpel/200709/msg00038.html
      
http://lists.oasis-open.org/archives/sca-bpel/200710/msg00021.html
      
http://lists.oasis-open.org/archives/sca-bpel/200710/msg00022.html

 

Alex Yiu: Latest email for Issue 5 : 

 

Alex Yiu: http://lists.oasis-open.org/archives/sca-bpel/200711/msg00016.html

 

Mark Ford: Danny summarizes issue

 

Mark Ford: Definition of static analysis 
required

 

Mark Ford: Martin: how does this differ than 
ws-bpel SA ?

 

Mark Ford: Danny: For the purposes of determining 
whether something is a service or reference you cannot evaluate the 
expressions.

 

Sanjay: There is no one in the Q, so I am fine with 
the free form discussion at the moment

 

Mark Ford: sorry 

 

Mark Ford: The WS-BPEL 2.0 doesn't include any 
language for static analysis of expressions

 

Mark Ford: Sanjay: We should identify the purpose 
of SA

 

Mark Ford: Martin: we're only doing SA for which 
end of plink a process implements. 

 

Mark Ford: Martin: All we have to say is that we 
need to ignore expression

 

Mark Ford: Danny: In agreement, but looking for a 
way to put into a coherent normative sentence

 

Martin C: we could say that sca static alanysis 
MUST ignore and and MUST NOT evaluate expressions

 

Sanjay: An SCA static analysis is the class of the 
valid static BPEL static analysis that does not evaluate expressions. The 
purpose of the SCA static analysis is to derive SCA Service and Reference for a 
BPEL process definition.

 

Mark Ford: Danny: we could vote on intent and let 
the editors fix it up

 

Sanjay: An SCA static analysis is the class of the 
valid static BPEL static analysis that does not evaluate expressions. The 
purpose of the SCA static analysis is to derive SCA Services and References for 
a BPEL process definition.

 

Mark Ford: change made to make Service and 
Reference plural

 

Mark Ford: Danny made motion to accept, Martin 
seconded

 

Alex Yiu: typo in "the valid static BPEL static 
analysis" ...

 

Mark Ford: Martin amends motion to have editors do 
"editorial fixup"

 

Mark Ford: Danny accepts as a friendly amendment, 
no objections

 

Alex Yiu: "An SCA static analysis is the class of 
the BPEL static analysis that does not evaluate expressions. The purpose of the 
SCA static analysis is to derive SCA Services and References for a BPEL process 
definition."

 

Mark Ford: Martin: editorial fixup does not change 
the intent of the text

 

Alex Yiu: s/the valid static BPEL static 
analysis/the BPEL static analysis

 

Mark Ford: Martin: in other cases, some motions 
will be crafted text and NOT to be changed by editors

 

Mark Ford: Danny: agrees with Martin that editors 
should have leeway in some cases but in other cases they should not

 

Mark Ford: no other discussion for ammendment, no 
objections

 

Mark Ford: +1

 

Mark Ford: Martin: clarifying the current motion: 
Have the editors insert the above text, making it read better

 

Mark Ford: Danny: email includes a from and to to 
help the editors identify where the change is needed in the spec

 

Sanjay: s/the partnerLink MUST be wired to 
corresponding SCA service/the partnerLink MUST be associated with the 
corresponding SCA service

 

s/the service MUST be wired using a binding/the 
service MUST be configured using a binding

 

Mark Ford: Sanjay: making a motion to 
ammend

 

Mark Ford: Martin: the motion is only about the 
wording for static analysis

 

anish does it matter, sanjay can make any amendment 
he wants. No?

 

Mark Ford: Sanjay withdraws amendment

 

Mark Ford: no objections, motion 
passed

 

Alex Yiu: +1 to Sanjay's suggestion

 

Sanjay: s/the partnerLink MUST be wired to 
corresponding SCA service/the partnerLink MUST be associated with the 
corresponding SCA service

 

s/the service MUST be wired using a binding/the 
service MUST be configured using a binding

 

Mark Ford: Summary: Issue 5 - part 1 on static 
analysis was passed

 

Mark Ford: Current discussion is Issue 5 - part 2 
on usage of term "wire" within the text

 

Mark Ford: Alex: suggests that all of the changes 
are grouped together to make the editing easier

 

Mark Ford: MArtin: people making proposals are 
responsible for providing the exact text

 

Sanjay: An SCA static analysis is the class of the 
BPEL static analysis that does not evaluate expressions. The purpose of the SCA 
static analysis is to derive SCA Services and References for a BPEL process 
definition.

 

Mark Ford: Martin: The first removal of wire is 
fine, but the second is consistent with the SCA text

 

Mark Ford: Sanjay: We need to produce a concrete 
proposal

 

Sanjay: s/the partnerLink MUST be wired to 
corresponding SCA service/the partnerLink MUST be associated with the 
corresponding SCA service

 

s/the service MUST be wired using a binding/the 
service MUST be configured using a binding

 

Mark Ford: Sanjay: Move that we do the changes that 
were cut/pasted earlier

 

Mark Ford: Martin: We need the whole text to 
provide the context for the changes

 

Sanjay: An SCA static analysis is the class of the 
BPEL static analysis that does not evaluate expressions. The purpose of the SCA 
static analysis is to derive SCA Services and References for a BPEL process 
definition.

 

Mark Ford: Sanjay pastes proposal for part 1 
(above)

 

Sanjay: If a an SCA static analysis of the process 
determines that it is possible that the first message for a partner link will be 
received in a <receive> activity, the <onMessage> element of a 
<pick> activity or the <onEvent> element of an event handler then 
the partner link MUST be associated with a corresponding SCA service in the 
component type. If the partner link declaration has initializePartnerRole="yes", 
then the service MUST must be configured using a binding that knows the identity 
of the partner as soon as the partner link becomes active (e.g. the binding 
cannot depend on using a reply-to field as the mechanism to initialize partner 
role.).

 

Mark Ford: Sanjar pastes proposal for part 2 
(above)

 

Mark Ford: Sanjay motions to change the text to 
read as above

 

Mark Ford: no further discussion on the motion, no 
objection, motion is passed

 

Martin C: martin 2nd the motion

 

Mark Ford: Sanjay: Still discussing issue 5, we 
have enough for a formal proposal now

 

Mark Ford: Danny: This change goes in Section 
2.1

 

Mark Ford: Issue 5 resolved

 

Mark Ford: Alex: was issue 14 opened?

 

Mark Ford: Sanjay: yes

 

Mark Ford: no other business, call 
ended