anonymous morphed into anish
anish: agenda --
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 Aug 20, 2009 minutes
http://lists.oasis-open.org/archives/sca-bpel/200908/msg00041.html
5. Action Items review
#0103 create alternate proposal for Issue 52 -- Najeeb
DONE
#0104 send new proposal for issue 41 -- Anish
PENDING
6. New Issues
a) Issue 56 - No scoping rules specified to resolve variable name referred by sca-bpel:multiRefForm extension for the partner link
http://www.osoa.org/jira/browse/BPEL-56
b) Issue 57 - No initialization mechanism specified for the variable with sca-bpel:multiReference extension
http://www.osoa.org/jira/browse/BPEL-57
7. Issue Discussion
7 open issues
a) Issue 52
CT generation (section 2.1.1) does not take into consideration the multRefFrom attribute
http://osoa.org/jira/browse/BPEL-52
Initial proposal: http://lists.oasis-open.org/archives/sca-bpel/200907/msg00037.html
Addendum to the proposal: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00014.html
Proposal from Anish: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00035.html
Alternate proposal from Najeeb: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00049.html
b) Issue 41
SBPEL2022 has an incorrect 'MAY' and is not applied recursively
http://www.osoa.org/jira/browse/BPEL-41
Email discussion -
http://lists.oasis-open.org/archives/sca-bpel/200905/msg00035.html
http://lists.oasis-open.org/archives/sca-bpel/200905/msg00041.html
http://lists.oasis-open.org/archives/sca-bpel/200905/msg00044.html
Proposal: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00011.html
Proposal v2: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00036.html
Awaiting proposal v3 from Anish
c) Issue 53
BPEL Process: References with Multiplicity 0..1 - how are they supposed to work?
http://osoa.org/jira/browse/BPEL-53
Proposal: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00021.html
d) Issue 54
sca-bpel:multiReference/@partnerLinkType and sca-bpel:multiReference/@partnerRole cardinality
http://osoa.org/jira/browse/BPEL-54
Proposal: in Jira
e) Issue 55
Co-occurrence constraints on sca-bpel
roperty attribute and sca-bpel:multiReference element
http://osoa.org/jira/browse/BPEL-55
Proposal: in Jira
f) Issue 46
SBPEL3006 isn't deterministic
http://osoa.org/jira/browse/BPEL-46
no proposal
g) Issue 50
Need more examples in the specification
http://osoa.org/jira/browse/BPEL-50
no proposal
8. AOB
anish: Chair: Sanjay Patil
anish: Date: 2009-08-27
anish: Agenda: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00050.html
anish: ScribeNick: Najeeb Andrabi
anish: Scribe: Najeeb Andrabi
Najeeb Andrabi: Agenda approved.
Najeeb Andrabi: meeting minutes approved for Aug 20th call.
Najeeb Andrabi: AI 103 and 104 done.
Najeeb Andrabi: Danny moves to open issue #56; anish seconds.
Najeeb Andrabi: Issue #56 is now open.
Najeeb Andrabi: motion passed.
Mike Edwards: The discussion is absolutely about whether the issue is an issue
Najeeb Andrabi: Danny: Initialization of properties needs to extended to multi reference variable initialization.
Najeeb Andrabi: Danny moves to open #57; Najeeb seconds
Najeeb Andrabi: motion passed.
Najeeb Andrabi: Issue #57 is now open.
Sanjay: Alternate proposal from Najeeb: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00049.html
Najeeb Andrabi: Anish:Change SBPEL2004.2 to use "sca:reference" @name attribute
Najeeb Andrabi: Mike Edwards: Always, use partner link name as the name of the multi-valued reference.
anish: 30004 is a little convoluted
Mike Edwards: one way to model the multi-ref initialization would be to represent the extension as a) a simple extension attribute on the variable declaration element
Mike Edwards: and b) the initialization of the variable be represented by an extension child element of the variable declaration that in effect is an extended <from/> element, similar in form to the standard <from/> element
Mike Edwards: which I think addresses one of the points made by Danny in our earlier discussion
Mike Edwards: since the idea of the SCA initialization of these variables is precisely that of an extended form of initialization, where the data for the initialization is coming from a source outside the process
anish: this is making me think, are multiRefs such a mismatch to BPEL?
anish: if so, what if we didn't support then in BPEL C&I?
anish: s/then/them/
Mike Edwards: they are not a mismatch to BPEL at all
Mike Edwards: BPEL spec describes the assignment of an EPR to a partnerLink variable
Mike Edwards: so the EPR had to come from somewhere - and the somewhere is a variable of some kind
Mike Edwards: the BPEL spec even has a datastructure type to hold these EPRs
anish: k, understood. I was mostly thinking aloud. It seems like multiRefs stumps everyone. I had to explain to some of our devs how they work, as they were completely baffled about it
Mike Edwards: we *could* make it illegal
Mike Edwards: ie multirefs for BPEL
anish: that is what I was pondering
anish: whether that makes more sense
anish: and simplifies the spec quite a bit
Mike Edwards: but you might ask your devs to think about the case where a process needs to get some data from a set of equivalent services - eg a set of prices for some widgets
Mike Edwards: from a whole series of suppliers
anish: i don't think the problem is the usecase
Mike Edwards: that looks to me like a sequence of calls
Mike Edwards: using the same partnerlink in a loop, with the target EPR changing each time you go round the loop
anish: the problem is that everyone seems to stumble on it and the BPEL-centric folks certainly don't get it right away
Mike Edwards: so then, where did the list of EPRs come from?
Mike Edwards: if we use the wired-by-Impl paradigm, the list *could* have been sent to the process in a service invocation
Mike Edwards: ie it arrives as the value of a message variable on a receive, say
Mike Edwards: that variable then contains a list of EPRs and I assign them one at a time to the partnerLink
Mike Edwards: I think that our SCA multi-ref variables are the exact parallel to this
Mike Edwards: except that SCA provides the set of EPRs on a plate rather than having to use a receive
anish: i don't disagree Mike
Mike Edwards: ok, good
anish: i think we'll have to do a better job of explaining this in teh spec
anish: cause readers get stumped on it
Mike Edwards: oh, I can agree with that 
Mike Edwards: it may be useful to start with a scenario just like the one I described here
anish: +1