OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Raw minutes from 03-SEP-2009

[7:57] anish: Agenda --
[7:57] anish: 1. Roll Call

2. Appointment of scribe
Scribe list attached below

3. Agenda bashing

4. Approval of Aug 27, 2009 minutes

5. Action Items review

6. New Issues

7. Issue Discussion

a) Issue 52
CT generation (section 2.1.1) does not take into consideration the multRefFrom attribute
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
Latest proposal from Najeeb: http://lists.oasis-open.org/archives/sca-bpel/200909/msg00000.html

b) Issue 41
SBPEL2022 has an incorrect 'MAY' and is not applied recursively
Email discussion -
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
Proposal v3: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00051.html

c) Issue 53
BPEL Process: References with Multiplicity 0..1 - how are they supposed to work?
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
Proposal: in Jira

e) Issue 55
Co-occurrence constraints on sca-bpelroperty attribute and sca-bpel:multiReference element
Proposal: in Jira

f) Issue 46
SBPEL3006 isn't deterministic
no proposal

g) Issue 50
Need more examples in the specification
no proposal

8. AOB
[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.

S/MIME Cryptographic Signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]