[7:58] Danny van der Rijn: Scribe: Danny
[7:59] anish: Date: 2009-09-03
[8:00] anish: Chair: Anish Karmarkar
[8:00] anish: ScribeNick: Danny van der Rijn
[8:00] anish: Scribe: Danny van der Rijn
[8:04] Danny van der Rijn: Topic: Issue 52
[8:05] Unknown/malformed action: /Topic: Issue 52/Topic: Approval of Aug 27 minutes/
Check ?help
[8:06] Danny van der Rijn: s/Topic: Issue 52/Topic: Approval of Aug 27 minutes/
[8:06] Danny van der Rijn: minutes approved
[8:06] Danny van der Rijn: Topic: Issue 52
[8:06] Danny van der Rijn: Najeeb has a proposal out.
[8:06] Danny van der Rijn: Najeeb: I've made changes based on our last conversation.
[8:06] Mike Edwards: greetings
[8:11] Danny van der Rijn: discussion around getting rid of 2004.2 in proposal
[8:11] Mike Edwards: I have to say that is for discussions like this that desktop sharing technology would help a LOT
[8:11] Danny van der Rijn: 
[8:15] Mike Edwards: [SPEL3011.1] A variable with the sca-bpel:multiReference extension MUST be referenced by one and only one partnerLink element with an sca-bpel:multiRefFrom attribute
[8:16] Danny van der Rijn: furthermore ".. by *the* one and only one pL .. which *it* references" ... ?
[8:18] Danny van der Rijn: Mike E: As Mike R pointed out, 2 pL's couldn't share the same variable. Does this bother us?
[8:22] Danny van der Rijn: Mike E: Do we need the ability to have (nested) pL's that don't get exposed
[8:22] Danny van der Rijn: Martin: I think we need that
[8:22] Danny van der Rijn: +1
[8:23] Danny van der Rijn: Mike: Better to assume exposure and have to explicitly suppress
[8:23] Danny van der Rijn: Martin: agree
[8:23] Danny van der Rijn: +1
[8:23] Danny van der Rijn: Anish: separate issue
[8:24] Danny van der Rijn: Mike E: Say I have inner partnerLink declared, and mark it with 'skip' -- I'm still able to copy an EPR into it programmatically.
[8:24] Danny van der Rijn: Action: Mike E to file an issue as above
[8:29] Danny van der Rijn: Anish: What's the value of plT and partnerRole in the multiRef vbl?
[8:29] Danny van der Rijn: Najeeb: it makes an association
[8:29] Danny van der Rijn: Anish: the runtime is going to the "exactly one pL referencing it" check already.
[8:30] Danny van der Rijn: Anish: So now you've got duplicate information that needs to be kept in sync by the editor
[8:30] Danny van der Rijn: Danny, Mike E: +1
[8:31] Danny van der Rijn: Mike E: a pL that point to a variable in effect says "go initialize this variable for me"
[8:32] Danny van der Rijn: Najeeb: OK with removing the attributes
[8:32] Danny van der Rijn: Anish: If we do that, that would take care of another of my comments
[8:33] Danny van der Rijn: Anish: One more comment left - proposal talks about throwing an exception rather than generating an error. Rest of spec talks about generating errors.
[8:33] Danny van der Rijn: Anish: (Separate Issue - we don't really say what generating an error means...)
[8:34] Danny van der Rijn: Action: Anish to file that separate issue
[8:37] Danny van der Rijn: Danny: can remove 3005.1 since this case would have been rejected by static analysis
[8:39] Danny van der Rijn: Anish: reworded 3011.1 takes care of the need for 3005.1. Remove 3005.1
[8:39] Danny van der Rijn: Anish: reworded 3011.1 takes care of the need for 3005.1. Remove 3005.1
[8:40] Danny van der Rijn: Mike E: If we are able to characterize property-setting and multiref from as vbl initialization, we should do so, and disallow other initializers on those vbls. I'll raise such an issue.
[8:43] Danny van der Rijn: Najeeb: I came up with a virtual initialization expression explaining how the variable gets initialized
[8:43] Danny van der Rijn: Mike E: Don't like example. Problem is in implying $SCARuntime.xxx exists
[8:44] Danny van der Rijn: Najeeb: OK with removing example.
[8:45] Danny van der Rijn: What about just <from> <i>value that comes from property</i> </from> ?
[8:46] anish: s/property/reference/
[8:47] Danny van der Rijn: Actually, more like <i> <from> value that comes from the reference </from> </i> (italicize the whole line, not just the contents of the <from> tag)
[8:50] Danny van der Rijn: <from> <i> extended expression that contains the injected value </i> </from>
[8:53] Danny van der Rijn: Anish: enough changes that would require a new version of the proposal. Najeeb to produce it.
[8:53] Mike Edwards: actually you dont extend <from>
[8:53] Danny van der Rijn: Anish: Hopefully, we can accept the edited proposal quickly next week
[8:53] Mike Edwards: you have an extension element that replaces <copy/>
[8:53] Mike Edwards: and that extrension element can contain pretty well anything
[8:54] Danny van der Rijn: @Mike - exactly, so it replaces the from and the to, so there's no extension of from itself. So we're good on the proposed wording?
[8:54] Danny van der Rijn: s/extresnsion/extension/
[8:54] Danny van der Rijn: s/extrension/extension/
[8:56] Danny van der Rijn: Najeeb: picture in section 3.2 needs to be changed as well if we go with this proposal
[8:56] Danny van der Rijn: Anish: Dieter has the source if you don't. Or Mike Rowley.
[8:57] Danny van der Rijn: Anish: Or could resolve with action for editors to fix.
[8:57] Danny van der Rijn: referee calls time. Straggler roll.
|
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