Diane asks if there are objections to approving current draft of spec. Danny objects that he hasn’t had time to read it yet. We will vote next week on latest version of spec.

Issue 51

Alex: Yaron and I have been discussing on the email list. I added 2 small bits of syntax that may address Yaron’s concerns.
Yaron: overall, I’m happy with one exception. You cannot rely on a message coming in is valid. I’m concerned from the perspective of portability, that an author of a BPEL executable, you don’t know whether the engine will validate, you might specifically be writing for one that doesn’t. You might get a message that’s screwed up in “expected ways.” But if you deploy on another engine, then everything blows up. I’m wondering if we want to provide a switch that explicitly states the expectation of the programmer. We’ve already got it on copy.
Dieter: wouldn’t that be in a deployment descriptor?
Yaron: by externalizing it to config, you lose portability, since configs aren’t ported.
Dieter: QOS attribute.
Satish: If you believe in web services contracts, then you are using them, you have to assume that underlying infra is honoring them.
Yaron: instead of saying “typically…” say something else. wordsmith. 1^st green para, 3^rd green sentence. spec shouldn’t be saying that.
Alex: what would you suggest?
Yaron: thinks.
Satish: I think what it’s saying is that the XML instances, copying source to dest, basically at runtime, whatever infoset you’re assigning must conform to the type declared at the destination.
Alex: they need to be compatible if they are known.
Satish: only if validate switch is on.
Alex: validate on activity, validate on assign. real runtime validation will be run to make sure that manipulation results conform to the schema. If there’s an inbound message followed by an assign. Underlying infra provides guarantee, then source known to be valid. Static analysis, even if validation on the assign is set to no, we can do static analysis.
Yaron: no we can’t. standard XQuery PSVI problem. a message shows up, I know it was validate, put flag on it, say it was validated. immediately after assign with validate=no, even if you can prove that the assign will be invalid (black case), you still can’t reject it, because the validate switch is set to no. Intentional for incremental buildup. Instance may not be valid while it is being built. Before then, if validate is no, you’re saying you know that it might fail.
Alex: I see what you’re saying.
Satish: Agree.
Yaron: what if the assign says validate=yes? In that case, static analysis makes a lot of sense. Static analysis error would be good.
Satish: are we trying to dictate what analysis can be done?
Yaron: no
Satish: There are all kinds of constraints specified by the flag. We’ll get into a black hole trying to specify them.
Yaron: agree. make clear when can assume when vbls are valid.
Danny: are you allowed to reject the process?
Yaron: Say there’s some case where you can prove that something will fail. Question before the group is If someone finds a case that someone can prove that the process will fail, can they reject the process?
Satish: at this point, the less language we try to put in, the better.
Yaron: we should edit 51 to make it clear. 51 should turn into a very clear description of validation semantics.
Satish: in other words, we should be clear about the constraints. We assume for inbounds, the contents are valid.
Yaron: no we don’t
Alex: part of 160, processor may provide means to turn on or off message validation.
Satish: I thought we were going to assume that they’re valid.
Yaron: general principle here. Satish is giving us the right direction. It’s an optional feature. Should we be able to statically analyze in places that the spec doesn’t say? Static analysis, which is optional, should leave it out of the spec. Nothing you’re proposing, Alex, talks about requirements.
Alex: agree that we should minimize, but we should mention it.
Satish: not normative language.
Alex: MAY. that’s pretty weak already. agree that we should minimize
Yaron: lowercase “may”
Alex: drop green text?
Yaron: need to see new wording. we can potentially drop green text if we’re turning static analysis into footnote. but we might need more clarification that when validate=no, you can’t do anything. Sometimes validate=no for performance reasons, sometimes because you know that you’re doing something illegal.
Satish: in other words, when is the PSVI flag on?
Yaron: yes
Alex: we have differing expectations. In one dimension we are clear. Most of the people won’t turn on the flag until a later point.
Yaron: so what we’re really saying is that we need 2 switches (not suggesting it), one for performance, one for
Ivana: validate=no doesn’t mean that we’re doing something illegal.
Satish: since we say don’t validate, you can’t assume that it’s valid.
Ivana: but “no” is the default
Diane: we’ve been talking for 25 minutes
Yaron: we’re not going to vote today, but we need to edit spec to completely downplay static analysis.
Alex: OK. remind other people that 51 has other text not related to static analysis. If people use XPath 1.0 model, there will be no runtime type checking. We should point that out.
Yaron: let’s not talk about static analysis at all.
Alex: in terms of static analysis, we just have 2 sentences if we ignore green text, back to original
Yaron: why do I need the analysis language in the text there?
Alex: let’s park the issue.
Diane: and do what with it? If it’s just a disagreement, then a vote is appropriate, but if there’s work to be done, what is it?
Satish: I would like to take this offline to understand the argument.
Diane: If half the group wants to take it offline, let’s keep it online.
Alex: First sentence (after update the third bullet)… is from the original spec
Satish: What is it trying to say? It’s not from the original spec.
Alex: first sentence trying to apply consistent terminology with rest of spec. the source value must process type associated with dest. when we do assign/copy, validate=false, should we still have case where underlying model is schema aware, should there still be a mismatchedAssignmentFailure?
Yaron: goes back to original
Satish: if validate=no, can’t do validation.
Alex: goes back to major clarification of what does validate=no mean? No validation at all? 2 switches?
Dieter: unconstrained
Yaron: paraphrase. Alex is unhappy with validate=no. Oracle is going to do PSVI…
Alex: lots of extrapolation
Diane: next Alex will tell what BEA is doing
Yaron: .. to do analysis of types to tell people that stuff won’t work. But we’re making that impossible.
Alex: most likely I will agree to drop this, I just want to make sure there’s nothing there that’s worth keeping. Especially mismatchedAssignmentFailure.
Yaron: we have it if validate=yes
Alex: if underlying data type says it can’t do it, which wins?
Satish: static is about catching runtime errors early. don’t need to say something about it. if we’re not mandating static analysis, we simply need to say what the runtime error would be. if you can “pre-catch” the error, how you present that to the user is your own business.
Yaron: example: implementation maps simple types to java types. try to do assign from one to the other, we’re not going to translate, it’s going to fail, no matter what spec says. hope we could catch that during static analysis. point is that there are going to be a lot of niggling details all over. spec needs to say that if validate=no, you can’t say anything.
Alex: all bets are off at runtime. static analysis is implementation issue. do we still have mismatchedAssign error?
Dieter: no.
Alex: validate=no, no error at all.
Satish: some other error?
Alex/Yaron/Dieter: there’s already one there.
Alex: fine with potentially dropping bullet. but would like to reread this a number of types.
Yaron: bpws:invalidXMLError
Diane: summarizing: result is that there will be a friendly amendment to delete the 3^rd bullet of the proposal. How long do you want to have to consider it?
Alex: Charleton is involved
Diane: we’ll defer it, checkpoint tomorrow morning. see if we’re ok to vote, or if there’s a different proposal. Alex will consider current amendment and see if he accepts as friendly. Charleton, have you heard enough?
Charleton: yes.
Dieter: what about inbound data?
Yaron: already language in spec that says that you can’t make any assumptions. (160)
Satish: I would interpret this that it’s OK for an implementation to know how it is configured, and apply static analysis on it.
Diane: so what are we doing on 160?
Alex: editor needs to put that language back in.

Issue 125

Yuzo: Problem is how do we write literal in from spec. We need to fix it. based on our decision for 157, we’ve introduced <literal> which is part of the solution. We need to make sure that we know what that element corresponds to.
Yaron: Are you asking the same question that’s in another issue? I.E what’s are the semantics of an empty from literal?
Danny: do we always parse as XML?
Alex: yes
Yaron/Danny: let’s say so. Group: Q1 both examples are valid. All examples look good. Issue probably no longer valid.
Alex: we need to clarify how we parse stuff within <literal>. Also need to clarify what <literal/> means. (empty literal).
Yaron: source of copy is empty -> illegal, so <literal/> shouldn’t be empty. Should be treated as empty string.
Alex: may want to use this issue to fix amendment from 157. will give us trouble when trying to assign to simple string variable.
Yaron: I thought we put in language that allowed us to have a TII that has nothing.
Alex: we adopted amendment from Danny to make that certain case illegal. String variable can’t be initialized to empty string.
Yaron: consequence of what we’re talking about is that there’s no way to have a simple type string variable that is empty.
Alex: we need to make an exception case.
Satish: you’ll figure it out.
Alex: 125 todo list: <literal> is processed as XML. Is there a consensus on what <literal/> means.
Yaron: can’t separate issues; declaring that it’s an empty string in current spec is just mean.
Danny: not comfortable with <literal/> being empty string.
Yaron: didn’t want situation where copy can delete. This would do that.
Alex: that was bigger scope amendment that failed. Smaller scope amendment disallows deleting of elements, but not text nodes.
Yaron: we’re abusing InfoSet.
Alex: And we’re trying to bridge the gap between it and a known expression language. We should have a dependence on a richer data model at some time in the future. 125 is good to go, but we still need to clarify what <literal/> means. empty TII. we also need to fix the friendly amendment to 157.
Danny: I still don’t understand the fix, but I guess I’ll see it later.
Diane: Yuzo, since you had a proposal, do you want to write it up?
Yuzo: I’ll try.
Simon: what does that mean for 125?
Yaron: 125 gets hijacked.

Issue 120

Danny: I propose that 120 and 120.1 be closed with no change to the spec
Satish: second.
Dieter: we still have a statement that if there are multiple initial receives that there MUST be correlation.
Alex: do we still need that requirement?
Yaron: today, yes.
Yaron: in order have the rendezvous case, we need to have correlations. There’s a difference in allowing it, and making it possible. If you don’t require a correlation set..
Satish: Do we ever need to assert that a receive/createInstance has a correlation set attached to it? The philosophy has been to be silent about possibility of engine-managed correlation. Not explicitly disallowing, but not saying anything about it. As a consistency feature, there is no reason to require, but I’d have to think about it. For example, if some of the receives, have correlation sets, then what?
Yaron: elephant issue.
Danny: hijack 120?
Yaron: yes, use it to throw away multistart requirement.
Diane: Are you proposing an amendment to the current proposal?
Satish: yes, but I need to look at the current spec before I state it.
Diane: rather than close with no change, we should close with a statement that the spec should say nothing, to catch anything that’s in the spec currently. Satish – how long will it take?
Satish: maybe tomorrow.

Issue 120.2

Yaron: The issue is that this is a consequence of Ping messages – no parts, so can’t correlate on them. If there are 2 pings that need replies, how can you match it to the right request?
Dieter: from the eventHandler context.
Danny: why is this not relevant to all request/replies in event handlers?
Satish; confusion is: there is a conflictingReceive case if there are 2 receives that are enabled at 2 different times. EventHandlers is a parallelism factory,and it has a receive. It apparently has a conflicting receive, but it is scoped. reply can only happen in that instance of the event handler.
Yaron: not currently in spec. issue is that you can’t use partnerlink trick, because they share them. same for messageExchange. if you expected to do a receive, then there would be some unique value. reply would have unique value as well.
Satish: that does much more than we’ve ever said for correlation on outbound message.
Yaron: ping message is degenerate case. You can’t do request/response using a ping today.
Satish: unless we make it clear how multiple event handlers don’t conflict because the reply is scoped to the handler, then we still have the issue.
Yaron: another related issue to bring up – 227 – parallel forEach has the same problem.
Danny: 215 as well.
Yaron: either we think really carefully about how to connect receives and replies,
Satish: I originally proposed that messageExchange be scoped
Yaron: that was my other approach. The scoping and matching rules will be messy and we’ll never get it right. If we made messageExchange values declarable on scopes, this would fix things. If I remember correctly, we discouraged declaring it on a scope because it was too heavyweight, and encouraged scope proliferation.
Dieter: it was 123. We should reopen it.
Alex: we originally had 3 options to consider. we should go back to them. 215 is not related to message exchange. it’s more related to 120 and 120.1 Yes there will be receives in parallel foreach.
Satish: anytime you have a conflictingReceive problem it’s in the semantics of the spec, because you’re already in the instance, so it’s not correlation based.
Alex: let me describe what I’m talking about . If you have parallel foreach and each branch does an invoke and a receive. it works in our implementation today.
Yaron: but you’re using magic to do it.
Alex; if there’s no engine magic, then there’s a fault.
Yaron: what you’re saying is that there are certain kinds of correlation that the spec takes on to make work. There’s another kind that the spec doesn’t deal with. like 215. If you don’t have disambiguation, the spec doesn’t take responsibility and there magic happens.
Danny: you’re using magic in all 3 cases.
Alex: this receive
Danny loses a bunch of conversation while he participates in the conversation..
Yaron: request/reply by its nature requires engine-managed correlation. what 215 would be doing is extending that and saying that there needs to be engine managed correlation on an invoke and a receive. we’ve put a mandate on the implementer to correlate invokes and receives.
Diane: we’re over 30 minutes. Need a new minute-taker before we leave for lunch.

Agenda discussion for after lunch.
What are we doing on 120.1? Reopen 123? I propose that after lunch we look at 123.

**** Break for lunch ****

Alex Yiu took minutes after lunch.

Issue 123

Diane: Should we re-open issue 123?
Satish: Do we explicitly where declare scope? Or implicitly calculate where to declare MessageExchange. For implicitly calculation, we will face a number of corner bug case.
Yaron: agree.
Danny: Me "three".
Satish: Event Handler is a scope.
Danny: Event Handler does contain a scope as of Issue 204, which was resolved.
Danny: Similar to <invoke>, can we make <onEvent> itself of "scope"?
Chris: Problem of not making <onEvent> itself a scope has a forward reference issue.
Satish: do we need something special to identify some message variables are used on <onEvent>.
Alex: why we need to change style of syntax now?
Danny: we are adding piecewise ... very confusing.
Diane: are we agreeing on something?
Yaron: We can separate the semantic and syntax of <onEvent>.
Rania: We may not want to argue so much on syntax issue. Some discussion on whether <onEvent> is an activity.
Alex: <onEvent> is not an activity. We should not use XML schema to dictate the activity.
Diane: Let's make a motion that resolve for Issue partially.
Yaron: I make a motion that: "Allow partner links and, when introduced message exchange attribute declarations to be declared inside the scope element inside the <onEvent> element, to be forward referenced by attributes used by <onEvent> ... For purpose of resolving values refernced by <onEvent> attribute name resoluation will occur as if the refernce happened in thes cope contained in the onEvent element."
Danny: that's why we may not separate the syntactic and semantic issue. To take all the attribute and elements that we care from scope and put them on <onEvent>.
Alex: questions on declaration of partnerLink, message-variables, message-exchange.
Danny: we are willing to going through attributes and elements.
Alex: if we go for Danny's proposal, we should go all in. Take all <scope> attributes.
Yaron: we may want to ban the implicit declaration of message Exchange. One outside receive and reply happens within onEvent. Wait a minute ... We need some reconsideration.
Chris: how about <sources> and <targets>?
Danny and Diane: Danny's new proposal merged with Yaron's proposal: "To take all of attributes and elements that we care about (tbd later) from scope and put them on onevent. ... Allow partner links and, when introduced message exchange attribute declarations to be declared inside the <onEvent> element, to be referenced by attributes used by <onEvent> ... For purpose of resolving values referenced by <onEvent> attribute name, partnerLinks ec declared in the <onEvent> scope come first. "
Ivana: asked about the status of this vote and which issue this vote is targetting at.
Danny: Make a motion to rescind the resolution of Issue 123.
Satish and Ivana both seconded the rescinding the resolution of Issue 123.
Satish: The intent of new resolution of issue 123: Each the messageExchange will now be declared explicitly local in a specific scope. Any messageExchange that is used on a message operation will be resolved to such a declaration and only then will it be legal.
Danny: asking how to proceed discussion
Danny: is there any problem caused by this proposal.
Satish: One side effect we can throw missReply fault earlier when the scope of messageExchange declaration ends.
Alex: What would be the matching rule?
Satish: we do not need to change the matching criteria: the matching will be based not just messageExchange: It will be based on partnerLink, operation and this messageExchange.
Danny: two messageExchange of the same name in two scopes used by <recieve> and <reply> in different scope would trigger fault. Confirmed that with Satish.
Diane: Go for the vote. Is there any objection? No objection. We pass this partial resolution.
Satish: I will volunteer writing up the formal proposal.
Chris: Propose to close issue 227 without changes since it will be handled by the new resolution of Issue 123.
Simon: second it.
Diane: Go for vote. Any objection. No objection. It is passed.

Issue 120.2

Alex: Do we allow not using variables in a <receive> operation and etc for zero-part message?
Danny: No. we voted down on that design.
Danny: whether we want to apply the current draft directional proposal of 120.2 ... to apply parallel forEach.
Satish: I don't see motivation to apply the design pattern to parallel forEach.
Diane: tried to keep track with agenda.
Diane: 120 and 120.1 - Satish to think about proposal.
Satish: 120 and 120.1 are about the multi-start situation.

Issue 169:

Yuzo presented the proposal. (issue-169.pdf) (Sept 12, 2005)
Dieter: asked about why Yuzo prefers "all links evaluate to false".
Yuzo: Because links can cross scope.
Danny: Is link status more associated with the activity or the enclosing scope of the activity?
Danny: the other reason I like Yuzo's preferred proposal: it gives consistency. The fault is relatively serious. It is not a business logic fault.
Satish: If we want to that consistent behavior, make it the scope isolated. It is just like other cases.
Alex: If we do not pick "all links evaluate to false", we should guarantee that one fault in one of transitionCondition, then we still attempt to evaluate rest of transitionCondition.
Dieter: It is just like other parallel activity.
Satish: If we want to make it really predictable, we may want to make the evalation order sequential instead of parallel.
Danny: We want to say something explicit here.
Satish: I prefer "All the remaining evaluate to false".

John E. started taking minutes at 3 PM PT

Issue 169 discussion continues

Yuzo does not yet have a formal proposal (see http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/14320/issue-169.pdf)
Satish: Prefer sequential in order of definitions or parallel in arbitrary order
Danny: Pvents from evaluating things in parallel
Satish: Parallel doesn’t buy you much because they are inherently evaluated as sequential. (Sequential order will give you predictability.

Satish: Links outside the scope will be propagated and inside doesn’t matter (because the scope has faulted)
Diane: Proposal?
Frank: Not opposed to sequential order (as defined in Yuzo's "draft" PDF proposal
Yuzo: Agreed to make this a formal proposal
Yuzo: Happy with Satish's proposal
Diane: Motion to define the order of evaluation?
Yuzo: Motion for sequential order
Diane: Part 1 is defined as Sequential in order of definitions in the source. Part 2 is "defined as all the remaining evaluate to false".
Simon: Does this change the semantics? (Simon and Satish briefly discuss a scenario, after which
Chris: A lot of companies have "deisgner tools" to create links. The order of evaluation seems part of this. The user is not necessarily thinking about the order in which these links are evaluated.
Satish: We cannot make it predictable, so people don't necessarily think about false transition conditions
Chris: These are probably just bad process examples
Danny: This doesn't hurt users at all - what they are using now is completely unpredictable.
Chris: Predictability is probably not that critical
Satish: This is the simplest solution - the behavior is already specified in other parts of the spec. Either the targets are inside the faulting scope (in which case they cannot execute) or outside the faulting scope
Danny: Only if it hasn't been evaluated yet. Two issues: which fault gets thrown, and if something is true which one gets evaluated
Chris: If the transition condition is known, and you can evaluate a join activity which can evaluate to false - who faults first?
Satish: This is an edge case.
Chris clarified Satish's point: Allow the scope to false prior to evaluating any of the links, all outgoing links should then become false. This simply means that transition conditions are not evaluated (part of Part 2 of the proposal)
Chris: Scope termination must be further clarified in the spec
Danny: How is this specific to the transition condisitions becoming false? Are transition conditions evaluated atomically?
Satish: Chris' point seems to be that it seems strange that we don’t know in what order faults will be evalutaed
Alex: Undeterministic due to parallelism
Satish: Every link has a transition condition - either a default or inferred one. Number 2 needs to address the fault behavior for a scope, not for the transition conditions
Danny: All transitions out of a scope which has not yet been evaluated become false if the scope is faulted.
Satish: Part 3 is now moot because multiple errors cannot do this
Frank: What about the faulted link? It evaluates to false
Satish: There is no difference between a transition condition that faults and a transition condition that is not evaluated.
Diane added this as a clarification to Part 2 of the partial resolution for 169.
Yuzo motioned to make this a proposal
Danny seconded
Diane: Any objections to voting on this?
No objections, passed.
Danny: Perhaps we should just hand this proposal off to the spec editors and let them add it to the spec
Everyone agreed that the wording in the proposal was strong enough to hand off to the spec editing team:

Issue 169: Transition condition error handling clarification

Motion to resolve:

Part 1 - If an activity has multiple transition conditions, the order of evaluation is defined as Sequential, in the order of definitions in the source.

Part 2 - If an evaluation raises an error, all the remaining transition conditions are not evaluated. This should be applied to the general case for fault handling. There is no difference between a transition condition that faults and one that is not evaluated.

Part 3 – Multiple errors will not be raised.

Passed, no objections. Will go to spec editing team for language.

Issue 142

Yaron motioned that Issues 4, 6, 6.2 and 142 should all be closed with no changes to the spec.
Ivana disagreed
Yuzo seconded the motion
Yaron: We're starting to debug our own spec. We need to focus on finishing the spec - adding in significant new features is a mistake at this point. The issues above are too late and we need to just close them and move on.
Frank: I partially agree - close 142 and 4 but am not sure about the others
Ivana: These issues are unrelated
Yaron: Issue 142 was specifically created to deal with the "threat" of Issue 6 and 6.2
Alex: This is why I closed 6.1 early
Alex: Move to make an unfriendly amendment to close 142 and 4 with no change to the spec
Danny seconded the unfriendly amendment
Chris: Issue 6 is more complex than 142. If we close 142 due to complexity then we should close 6 as well
Yaron: 142 is based on existing languages - 6.2 doesn’t exist in any language
Ivana: I think that break as it is propsed in Chris' email is straightforward. 6.2 is unrelated.
Simon: I understand that 6.2 with break and continue exists in programming langauge but which of these is a parallel programming language? These are designed to be sequential and its not a good fit into something parallel like BPEL
Ivana: Satish and Alex did a lot of work on completion activities - its only associated with Flow activities
Yaron: We've spent years arguing about 6.2. BPEL is a big, complex spec. Anything that deals with parallelism just makes things more complicated. If we are interested in shipping the spec we need to draw a line to stop adding new features. We're clearly running out of steam as a group - its time to decide what we shouldn't deal with.
Ivana: The issue is that Alex and I are working on a simplified version of 6.2 for tomorrow's discussion.
Yaron: There are lots of features in the spec we don't have. Where do we draw the line? For example - I cant specify that I need a message from a specific sender. Don't worry about extensions because you can't use BPEL without extensions. My best hope for BPEL is that it will establish some standards for this type of work. When do we draw the line against doing substantive work like 6.2?
Ivana: We shouldn’t be discussing our work, just discussing issues.
Yaron: This new piece of work will require a lot of work by the group to complete it. 6.2 is a new feature - there has to be a point where we say "no new features". Lets shut this down and ship the spec - we're done.
Danny: I suggest we all hear Ivana's and Alex's work tomorrow before including 6.2 in the issues to close.
Alex: The work that Ivana and I will present tomorrow is a simplification of earlier work - dropping the boolean condition. I also agree with Yaron in that this group is running out of steam. I think 6.2 should be the line - we should set a time-out mechanism for getting this closed or approved. We waited to 6.2 until Satish returned to see if he would be in agreement with the final decision.
Diane: Do you want to make an amendment to 6.2?
Alex: uhhh (gestures to Ivana)
Diane: The amendment currently under discussion is for closing 142 and 6 only.
Diane: We tend to have rathole discussions late in the day at an F2F that rarely result in anything. Before making a motion we should consider - what will a motion accomplish? We have discussed setting a deadline and then closing an issue. We also are planning to discuss shipping the spec. Yaron's points are correct by needing to shut this down and ship the spec. There is a balance point between a bad spec and a good spec - we need to find that space. Perhaps its better to think about timeboxing each of these issues and all of the others that remain open.
Yaron: Today we spent a large part of the day examining , discussing and re-evaluating specs that had been passed and closed in the past. I urge the group to remember that chances are good that parts of the spec will be wrong - at some point we need to draw the line and move ahead. We'll probably find issues during the final spec review as well. My proposal was a serious one - I really think that, given the work we have to do, and the work that is coming, when is it enough? It doesn’t matter how well defined the proposal for 6.2 is, its more work that we don’t have the resources for.
Dieter: Would like to hear and see what people will present tomorrow about 6 and 6.2. I will make a decision about these then. Regarding 142 and 4 I agree we should close these now.
Alex asked Ivana about timeboxing 6 and 6.2.
Ivana: I wanted to have a productive discussion.
Diane: How many people are in favor of the amendment to close 142 and 4 with no changes to the spec?

5 yes's in the room, 1 abstain on the phone
3 no's in the room, 1 no on the phone

Diane motion passed - we're now discussing closing 142 and 4 with no changes to the spec.

8 yes's in the room, no yes's on the phone
1 no in the room, 2 no's on the phone

Diane: 142 and 4 are now closed with no changes to the spec
Chris: Please mark 142 as revisitable in the spec.
Diane: OK.

Issue 11

Satish: Proposal to close with no change to the spec
Yaron seconded
Danny: We have two proposals on the table that we haven’t discussed in a while. If we are going to discuss these it should be with the proposers in the room.
Diane: We were told we should have a resolution to 51 and 157 before discussing 11.
Danny: I thought Yaron was going to do some research on this.
Diane: According to the minutes, Yaron was going to provide some information on Infosets
Chris: I'd prefer not to close 11.
Satish: What is the relationship between 157, 51 and 11?
Chris: Looking at whether the parent of the insertions was clear enough in the text that I had - I may need to make some adjustments to it. (Chris' mobile phone connection got worse) Can we discuss this tomorrow morning?

Issue 226

Alex: When I filed the issue there was a paragraph on faults that occur in handlers (eg 13.4.5). This addresses some of these problems but not in enough detail. There is no specific text discussing compensation handler to compensation handler calling. There is a bigger issue that the spec doesn't address - if a scope is a completed and the parent scope tries to invoke the compensation handler - what is the state of the child scope? (e.g. fault in a child invokes a parent fault handler - can the child compensation handler be "re-invoked" after the parent fault handler has completed?
Satish: Compensation is like a continuation on the scope. I don’t think we can claim this is unambiguously identified.
Yaron: I agree this is not clear in the spec. The installed compensation handlers are like a unit of work (like a scope) waiting to be called. When a fault occurs in the compensation handler the unit of work has been cancelled.
Alex: We've already discussed and passed this - see Issue 209
Yaron: There is another issue. If we're in a while loop there will be multiple compensation handlers that get called.
Satish: For while compensation handlers are called in reverse order.
Yaron: If the original compensation handler faults, what about the others in the while loop? Do we kill one instance? What about the other 4 (assuming we're looping 5 times).
Alex: 226 and 216 should be solved together since they are similar.
Satish: This is the consistency argument - the other problem is how do you write that compensation handler? If the compensation handler is re-invoked its got to "remember" how far it got before it faulted. We should keep in mind that when we do these things the logic for the compensation must be provided for - there is no easy way to write this type of logic.
Alex: Any subsequent attempts to call a fault handler would be a NO-OP
Dieter: Transactionally we are in an in-doubt situation. We should throw a failed compensation fault, allowing us to use the "magic" of Issue 190 to fix this problem.
Satish: The bottom line is that these are not real transactions. If the business logic fails there is not standard way to handle it.
Danny: If you have 5 instances of a compensation handler and the first one fails, you should just keep going. Its too difficult to use nested catches for faulting nested compensators.
Danny: Lets assume you are going to do 5 compensations serially how do you compensate the other four?
Alex: There is a problem with the compensation - it’s a positive/negative way to look at the issue
Yaron: Perhaps this could be handled using a trap. This can be coded but its horrendous.
Danny: Given the trap approach it seems like its at least possible to handle this.
Danny sketched out a scenario on the whiteboard

While executes 5 times (5 compensation handlers)

Two cases - one order matters, the other does not

If the first compensation handler fails and order matters you've got to stop (e.g. throw a standard fault)

In this case the desired behavior is to stop and ask for user intervention, because we're not sure how the other compensators should be handled

If the compensations are independent, go ahead and compensate them all
If one of the compensators throws a fault, there can be a fault handler inside the fault handler that catches the fault, sets continue to true, runs a compensation, then sets continue back to false. This allows a compensator to be re-invoked within a loop.

Satish: Syntactically this means to run a compensator again
Alex: While this is possible its not easy to code this logic
Satish: What about parallel for each? All of the compensators may be active using variables within a scope that has now faulted. Then what happens?
Yaron: This is Issue 216 and its still open.
Satish: We can run the compensations in parallel. What then happens when one of them faults?
Yaron: We should then cancel the others
Dieter: If one of the compensators throws a fault to the parent, the other compensators must be cancelled.
Satish: I don’t think we can re-invoke or compensate in any useful way in parallel for-each - they should be NO-OPs
Yaron: This sounds like a termination handler
Satish: This suggests that parallel for-each are a "unit" (much grumbling). The reason we apply reverse order is an approach to compensating while as a unit (sequential). It seems that our approach has been when we invoke a compensate action it is a singular approach, except for what is being proposed.
Alex: If a fault is not thrown by an instance of the compensation handler, the parallel for each cannot compensate independently. It may not be possible to compensate some things - for example materials may have already been ordered from a supplier.
Danny: You can respect control decencies or not - you cannot have both. It sounds like you are saying that you need to invoke compensatoin handlers serially for parallel in case one of them faults.
Danny and Alex began reviewing several scenarios in an attempt to understand how fault handlers should operate within a parallel scenario.
Yaron: This stuff’s so out there that we'll never know what everyone wants. We should take Satish's advice about compensating while as a unit.
Dieter: There are always situations in which an automated decision is not possible.
Yaron: When does a termination handler on parallel instances get called?
Dieter: Its not a termination issue. We need to freeze the process because the situation is not decidable. We should introduce a standard fault called "Compensation Failure"
Alex: Where do we catch it?
Danny: Where do we throw it?
Yaron: We had this debate regarding 190.
Danny: We need to freeze the process as soon as possible - especially in the case of deeply nested handlers.
Dieter: This appears to be the only option available.
Yaron: Not really-we could log something and then continue on.
Dieter: If we don't freeze immediately we'll lose the context of the fault
Yaron: There are two ways we can throw a fault - something goes wrong with the underlying system or you've thrown the fault yourself
Dieter: You're saying that usually what happens in a standard fault anyway.
Alex: We need to freeze a process asap
Satish: Or have some sort of audit trail. Any admin that is going to fix this is going to rely on an audit trail, not a complicated set of BPEL logic.
Alex: I'm going to make a motion to introduce a standard fault for Compensation Failure - can be thrown within a compensator. Compensator will be uninstalled and any subsequent calls to it are treated as NO-OP.
Dieter: Not sure if we need this new standard fault. It is unexpected for a compensator to throw a fault.
Alex: Example - I can cancel an Amazon order after it is placed but before it is packed and shipped. This is an example of a non-standard fault.
Dieter: Compensation is no longer possible at that point.
Satish: Invoking a web service in a handler may return a fault. If you forget to catch the fault it will propagate. It seems routine to be able to catch faults that may arise. I'm having trouble figuring out when you would want to freeze.
Diane typed up the following proposal based on feedback from the attendees:

Issue 226: Motion for partial solution – spec language to be provided.

When a fault happens, the compensation handler will get uninstalled.

Passed, no objection. .

Need to answer where the fault propagates to:

The fault will propagate to the caller of the ch including default fault and compensation handlers.

Passed no objection.

Note that this resolution needs additional wording to handle groups

Need to add sentence to 226 resolution for fault handling:

if a fault occurs in any of the ch instances then all the running instances will be terminated following standard BPEL activity termination semantics and all instances of ch are uninstalled.

Alex: Multiple instances will be addressed by 216
Alex made a motion based on Diane's notes, Danny seconded.
No objections to accepting the motion as written above.
The wording of the resolution needs additional wording added to it to determine how to handle groups once 216 is completed.
Alex motioned the updated wording. Charlton seconded.
The updated proposal has been passed

Issue 216

Diane: Do we have a motion?
Yaron: If we treat parallel for each as a unit this is easy.
Satish: 216 doesn't seem to mention while, only for each.
Yaron: While only deals with linear cases. For each is parallel, as does flow.
Satish: Flow is not a problem because of distinct names
Yaron: The best way to resolve this is to take a "package approach" to compensation - if one throws a fault we kill all the others. From a spec perspective this is easy.
Diane wrote up a motion based on this discussion:

Treat groups of ch’s under parallel for each and eventhandlers as a unit such that if a fault occurs in any of the ch instances then all instances are terminated following standard BPEL activity termination semantics.

For while, repeat until and sequential for each, the compensation of a scope nested within these activities causes the compensation handlers for all iterations of those activities to be executed in reverse order of the iterations.

For parallel for each and event handlers the compensation of the associated scope will cause the compensation of all iterations of pfe and all instances of the eh and there is no ordering requirement imposed by the bpel spec for those compensations.

Satish: The semantics of calling "compensate" is not stated - what does "compensating for a fault inside a scope" mean?
There were additional discussions about the draft motion that Diane typed up.
There was a general consensus that we should table this motion for consideration and additional discussion tomorrow.

Danny: Motion to recess

Allen: Second

Meeting recessed at 6:30 PM PT.

09/14

Meeting started at 9 AM.

Allen Brooks took minutes.

Issue 216/226

Danny: Definition of a group of fault handlers "A compensation handler instance group is defined to be all instantiations of a particular scope's compensation handlers."
Satish: 216 motion misleading. Already covered termination behavior when handling faults. Fault doesn't just terminate compensation handler clones, it terminates everything. Need to clarify how much is terminated.
Yaron: A fault in a compensation handler will terminate the compensation handler since the compensation handler cannon catch the fault.
Satish: Not clear from the current spec.
Yaron: Compensation handlers are acting like a half-featured scope, it has a default fault handler. We have language in scope for doing what we want to do in a compensation handler.
Satish: But that language calls for compensation when faults are caught and that is wrong here.
Danny: A compensation handler inside a compensation handler can only be called by a "default fault handler". Is such a compensation handler useless? If is useful then we need compensation handlers to have default fault handlers.
Satish: Effectively every compensation handler has a default fault handler that kicks in when a fault happens, which compensates any contained scopes.
Yaron: Just a model to describe what happens when a fault happens in a fault handler. Only other alternative is to say that fault handlers can't throw faults.
Satish: Fault handler in a scope, does some work, which undoes work in the scope. If a fault is thrown in the fault handler, including rethrow, compensation handlers will be called in the fault handler which undoes the work that undid the work in the scope.
Danny: You can put a guard around your compensation to distinguish between unexpected faults and rethrow.
Yaron: Compensation new semantics that are not part of other languages. We're not used to how this works.
Satish: Compensation handlers should have default fault handlers since they are a well defined activity. Fault handlers should not have default fault handler, not well defined activity, just trying to clean up when something bad happened.
Yaron: If you can have compensation handlers inside a fault handler then there must be a way to access them, which means the default handler is needed.
Yaron: 3 options: fault handler has default fault handler, fault handler do not have default fault handlers (1) compensation handlers inside fault handlers are not callable, (2) compensation handlers inside fault handler installed and can be called later by compensate activity.
Alex: If there is no scope in a compensation handler none of these issues exists. Also standard faults will not have this problem.
Satish: The behavior that we decided on yesterday implies a default fault handler but that adds additional behaviors that we might not want. Need to figure out how much of a default fault handler that we want.
Yaron: What we want is standard BPEL termination semantics.
Yaron: Having fault handlers have default fault handler gives us termination semantic and gives an answer to what to do with compensation handlers inside fault handler.
Satish: But may not be the right way to handle them.
Danny: What ever we do will probably be the wrong thing since we don't really know what people will want. Need to satisfy 80-20 case.
Satish: What Yaron called the simplest option (no default fault handler, compensation handlers not callable) is the right option.
Danny: In addition to default fault handler text should add recommendation to not add compensation handlers inside fault handlers.
Chris: Compensation handlers and fault handlers are running inside scopes and so scope should handle faults.
Satish: Fault handler not entirely in the scope in which it is defined or in the scope from which it was called.
John: Do we want to start writing this up?
Satish: First we need to decide which option we want to include.
Satish: Its worse than we thought since there are implicit compensation handlers as well as explicit compensation handlers.
Yaron: What ever we do will hurt someone. Need to figure out which hurts less.
Satish: Compensate is a normal activity. A compensation handler's default fault handler does nothing unless there are enclosed scopes with compensation handlers. In that case if there is a fault then the compensation handlers are called.
Yaron: If the Compensation handler exits normally then the enclosed compensation handlers are orphaned.
Yaron: The argument is the same for fault handlers so they should behave in the same way.
Yaron: Split the issue for compensation handlers, when a compensation handler exits normally then any contained compenstation handlers should be orphaned, when a compensation handler exists abnormally then if it exits the compensation handlers will be orphaned so a default fault handler is needed to call the contained compensation handlers.
Satish: motion - as a partial resolution to 226, in addition to yesterday's resolutions: A compensation handler that faults will undo its partial work using behavior analogous to a defualt fault handler. If a compensation handler completes successfully, then and compensation handler with it that were innstalled are now uninstalled.

· Motion passed.

Yaron: What to do with fault handlers? What to do when a fault handler faults? What to do when a fault handler completes?
Satish: When a fault handler completes there should be no compensation handlers.
Yaron: For consistency those compensation handlers become unreachable. This is already the case.
Yaron: What happens when a fault handler throws a fault? Either we have a default handler or we don't. Neither option is life and death. Can execute compensation handlers anyway by wrapping fault handler in a scope. Should we be able to compensate a fault? Yes. But shouldn't happen on rethrow. So least surprising would be to not have a default fault handler.
Chris: I disagree. Fault handlers should be installed on parent scope.
Satish: Originally thought about fault handlers as alternative completions for a scope but found that it led into a pit. Work in a fault handler is done to undo something, not a completion of work that is doing something. Undo work can be compensated but only in the context of the fault handler. Two fundamental choices: bother the parent scope with the fault or not. Rethrow is a perfectly normal choice that says that the fault is not local.
John: Do we still need language about groups?
Satish: Language from current resolution is not broad enough.
Yaron: Current model covers how termination works but descriptive language no longer matches model.
Satish: Just need to describe fault handling behavior.
Alex: Need to have distinct paragraph describing termination behavior.
Satish: motion to complete 226 - If a compensate activity is terminated due to a fault in the environment in which it was called then the termination of the work of the compensate activity occurs analogous to the default termination for a scope. (external fault)

· Termination of a compensation handler behaves analogously to the default termination handler of a scope.

· A fault in a fault handler causes all running contained activities to be terminated as specified in the spec. Then all compensation handlers contained in the fault hander to be uninstalled. Then the fault is propagated to the parent scope.

· Regardless of how a fault handler exits, any contained compensation handlers are uninstalled.

· If a fault handler exits without throwing a fault, any contained compensation handlers are uninstalled.

*** Break for lunch ***

Issue 226 continues

o Yaron moves that we pass the text elaborated in the hour before Satish seconds the motion

o Diane: Any further discussion ? – No Discussion. Any objection to accept this partial resolution? Partial in the sense that it is not the Spec language, but all known cases are covered.

o Yaron: We should sync up with 226

o Reads out the questions and sees if they have an answer to them.

o Q1: yes, is answered

o Q2: yes, is answered

o Q3: intentionally left out for the editors, but the model and mechanism are defined –

o Alex: suggest to add the Diagram back to the spec

o Danny: Well, we voted it out (issue 15?), now we need a vote to have it back, this is not left to the editors

o Alex: Correct. We need to vote it back in …

o Satish: But only after it is ‘fixed up’

o Satish: We will not close 226 BEFORE we have the actual language – general agreement

o Diane: any other questions or comments – no comments

o Diane: Any objections to adopting the partial resolution ? No objections – PASSED

o Diane: Since we have Paco on the phone, we do Issue 88. Paco sent out revised text last night.

o Paco explains some of the changes to the text. Paco also addresses some of the comments that were sent as responses in email.

o Addresses Monica’s Comment: I agree to add more normative language, i.e. “MUST NOT“

o Addresses Comment by Alex, Chris and Prasad that we should discuss.

o Paco accepts Monica’s and Yaron’s comments as friendly amendments

o Chris: I had comments associated with property aliases.

o Satish: The issues is that Property Aliases are not directly referenced, they are not QNames

o Chris: Danny opened a issue 228 that addresses that part, so I think that we can pass it as is. I will address my issues on 228 on that then.

o Alex: The non/transitive nature of import must be consisted with other standards, but I failed to find them. They are all defined as “non-transitive”. There is a spectrum of non-transitive which is not defined well, but since I cannot find it, I will not hold it back because of that concerns, I rather append that later.

o Chris: WSDL 2.0 is pretty clear on that. <reads out a part of section 4.2 of WSDL 2.0 spec>

o Alex: Ok, it says “using import is a necessary condition”.

o Chris: Why not state “if you use an element from a NS, that NS must be imported”?

o Diane: Ok, any other questions?

o Alex: Now people need to direct import stuff. A BPEL imports a XSD1, XSD2. XSD2 imports another XSD with the same TNS and import location. This yields to a conflict that happens *only* in the BPEL world, not in the XSD or WSDL processors ..

o <Danny draws a picture on a whiteboard>

o Satish: There are some implementation tricks that one could do to avoid this. But: NS are there to disambiguate things. So if a system is deliberately designed like this, there’s nothing we can do about.

o Chris: We have to allow that …

o Yaron: This is painfully inconsistent. This is only a thing in a schema-aware language. Either the value is visible and available, or it’s not visible and not available.

o Alex: yes, but there is also point 2 from my mail. If and only if we make it transitive, then we’re fine.

o Yaron : Why are why banning transitivity when we get ambiguity like this?

o Paco: To be clear on the import scenarios. You HAVE to import it directly

o Satish: If we need to import, this seems fairly clear. I fail to understand how you can say: ”You must give me the right hints”. It seems that the word “Hint” is meant to the location, not to the import.

o Satish proposes: The location attribute is a hint and that the BPEL Processor is not required to retrieve the document being imported from the specified location and remove the sentence that “The presence…” and the sentence after that.

o <Paco takes that as an friendly amendment>

o Alex: Going back to transitive/non-transitive discussion.

o Satish: I still fail to understand what the problem is: It’s just more labor to specify it

o Alex: I agree. But in terms of conflict resolution/conflict detection it should be transitive.

o Satish: If there’s a loader involved, the loader will detect the conflict. Is it BPEL’s responsibility to solve this? Why do we need to state this in the spec?

o Alex: Because the conflict only happens in the Process.

o Danny: But there is no conflict unless you reference a foo/someNS:a directly (referring to the example)

o Yaron: Let’s just go with the non-transitive approach

o Alex: It’s an illusion that more import statements gives us more safety.

o <Diane proposes to open a new issue, close it, mark it as revisible, and close 88. Or make an amendment to make it transitive and we vote on it>

o Alex makes an amendment: Make an import transitive.

o Nobody seconds the amendment – No Discussion on the amendment

o Diane: any other Discussion ? No more comments and discussion – we’ll vote <reads out the text on the whiteboard> Any objections ?

o Alex objects to adopting the motion.

o Alex makes an amendment to remove the paragraph that states about the explicit transitiveness, basically saying “leave this in the air”. Monica seconds the amendment

o Paco takes this NOT as a friendly amendment.

o Diane: further Discussion ? None. Any Objections?

o Vote: 3 in favor - 10 opposed – 1 abstains. – The amendment does not pass.

o Diane: Paco, have we covered Prasad’s comments.(not NS-qualified imports)

o Paco: Yes, it is consistent.

o Diane: any objection to adopt the original motion as appended by the friendly amendment

o No objections – Issue 88 passes.

o Diane: Issue 6.2 is next, then an hour on the new OASIS process, and we move 82.2 to Thursday.

John E. took minutes.

Issue 6.2

Satish: A sequence of 3 scopes – all complete unsuccessfully but do not throw a fault. This sequence will be counted as successful. Therefore the countCompletedBranchesOnly attribute (proposed by Ivana) is fairly useless.
Ivana: Need to recognize that things are exited, exited and completed successfully.
Chris: Call it Child Actitvities instead of branches – then call the attribute countSuccessfulScopedChildren or something like that.
Satish: All children of a flow that are not scopes if they complete without faults are always completed successfully, even if their work is not completed successfully.
Danny: We all agree on the semantics but not the name
Satish: The attribute is misleading - I question the meaningfulness of the use of this attribute, not its name.
Chris: Agree. What is the use case for this attribute?
Ivana: Flow with 3 branches, waiting for a message in all 3. If that receive fails you cannot count that you received anything. You can still wait for the other two, letting your flow complete successfully.
Chris: This sounds like a parallel for each and not flow.
Ivana: Parallel vs flow is that at design time you know the number of branches in advance or not. Its valid to have both options in the spec.
Satish: There were a number of concerns I raised about applying completion condition semantics to flow. One issue is the potential for links among various activities in the flow. For example, there may be different interchangeable suppliers - I don’t really care which ones complete, just that the number of expected suppliers do complete. The reason to have the flow, as Ivana just stated, is for convenience.
Yaron: Example - seven suppliers and I only need bids from three of them. I can create a termination condition when I receive three and tell the rest "sorry, no longer interested". We could do this with a flow and a completion condition for when 3 suppliers respond.
Satish: Other aspects include price, trust, etc.
Yaron: The argument is not whether we should use for each or flow but that the N out of M approach may not even be useful. For example, when the completion condition is reached the remaining processes are terminated with a "thanks but no thanks" message. For a business programmer they need to ensure they get N out of M so the termination cases will actually be run. Anybody writing N out of M using this mechanism will have to check for N out of M and determine which processes should be thrown out. Everytime a scope completes (or almost completes) you would have to have a mandatory sync point to freeze everybody.
Alex: Even if we have N out of M semantics there are still some missing features. For example, there may be delays in handshaking due to network latency and other issues. At least N out of M is never intended to be the complete solution.
Ivana: I think that this solution doesn’t cover all cases but maybe the most interesting (e.g. 3 positive reviews out of 5). The goal is to open the door for this feature and illustrate that we did think about this feature, make it available, and allow it to be extended in the future.
Satish: Messages may arrive too late. The machinery around the process must have some way to handle messages that don’t have a target anymore due to timing. We need to separate this issue from the business issues being identified.
Yaron: I think we recognize that this feature will not solve the world's problems. The whole reason why we've spent so much time discussing the BPEL extensibility model is that its easy for people to extend the spec to make it more useful. This suggested feature is "crippled" and is not necessarily useful as currently defined. Anyone using this feature needs to be a sophisticated user who knows exactly what they are doing and is capable of writing some extra clean up code to take care of unresolved issues. It would be remissive for us to add a proof of concept to illustrate that "more work cand be done here".
Yuzo: This proposal doesn’t go far enough. People will need better sync control, and access to variable processing. Using this N out of M feature is pretty difficult. This feature will not be used very efficiently. It also adds a new feature to an already large spec at this late date of the process.
Ivana: Objective is to give users a feature they can use easily in the future.
Yuzo and Ivana discussed the concept of sync control. Ivana emphasized that this was at the engine level, not the user level. Yuzo believes that isolated scope is good enough to handle N out of M cases. The lack of available data drastically reduces the usefulness of this proposal.
Ivana: We need to discuss the technical issues and then decide if we want to continue to work.
Alex: There is a tendency in the group where some of the features are a little too generic to be added at this point. I would like to propose a couple of amendments to add more detail to Ivana's proposal:

Amendment:

The completion condition feature can only be used for flow activities that exclusively contain scopes as their top level activities .

Dieter: I have a graph of hundreds of activities - some are scope, some are not. We can only use completion conditions with activities that contain scopes as their top level activities.
Danny: Why are we making people add a scope? Why cant we count a sequence as completed or not? It’s a needless constraint.
Diane: Second for Alex's amendment?
No seconds
Alex: New proposal - just apply this completion condition to parallel for each only.

Amendment:

Restrict the completion condition to apply to parallel for each only.

Seconded

Ivana: I accept this as a friendly amendment
Chris: At least with the isolated scope we can look at data and ensure things are where you want them to be.
Alex: We don’t have a flexible way to do parallel synchronization. Lets open a door and let people start thinking about the parallel synchronization issue. Perhaps in a future version of BPEL this issue can be addressed.
Chris: We could say that parallel for eaches can only be completed through serialized tests, allowing us to get some data for review - thereby enabling us to do a completion condition.
Diane: Any seconds?
Satish seconded the new amendment.
Alex: When we discussed this problem I told Satish we can solve this problem but it will require some major surgery on the spec.
Satish: Cannot allow data in a boolean condition to be arbitrarily updated in parallel conditions. N out of M requires you to review the condition before you complete the scope, not after.
Chris: The branches thing doesn’t make sense to me - we should call it an iteration.
Ivana: We can wordsmith it later - lets vote on this.
Diane: We need a formal motion to amend and vote on it.
Ivana: I make a motion to propose this as a solution.
Alex seconded.
Diane: We need to start reaching decision points - there is a lot of controversy and at some point we need to take a vote.
Ivana: I accept Alex's amendment as a friendly amendment.
Chris: I'd like to make an amendment based on my comments in a recent email.
Dane pulled up his email on screen so the rest of the TC could view Chris' comments.
Ivana: Chris' Point 1 - Branches is only calculated once and wont change as a result of the parallel for each execution. I accept this as a friendly amendment.
Chris' Point 2 - If you get to the end of a for each and somehow the count did not add up from the completion condition there is a new fault. This is the second friendly amendment
Chris' Point 3 - Change the description of the semantics of Activity Termination (13.4.4). This section describes that a termination handler cannot throw any fault. This language will have to be fixed. This was accepted as the third friendly amendment.
Chris: I don’t care how the language is fixed, just want to ensure its is fixed to align with Ivana's proposal.
Chris' Point 4 - Is branches the most suitable name to be used?
Danny: We really don’t have a name here - we should leave this to the spec editing team.
Ivana: I will rewrite the proposal based on feedback received from Alex and Chris.
Diane: We don’t have a final proposal to vote on now so we will defer the vote to our next meeting.
Alex: I'm not sure it needs to be re-written, the original proposal is not in spec language either and of all Chris' Points only the last one is a question and that one can be handled by the spec editing team.
Ivana: If people are comfortable we can vote on this today. I will accept as a friendly amendment that the spec editing team may change the term "branches" to reconcile with parallel for each if appropriate.
Satish: Is both N and M specified?
Alex: Only M is specified.
Satish: The fault is specified if the number of branches is smaller than M.
Chris: The runtime issue I referred to is different. The totals didn’t add up but not because M wasn’t big enough.
Simon: There is a logical flaw in the bidding scenario. Example - send out 10 bids, only want 3 back. What if only one comes back faulted, one comes back positive and nothing else comes back.
Ivana: You can establish a time-out condition
Simon: What would that mean in that context? When do you evaluate this?
Danny: You have to put that time-out in your business logic.
Danny: Why does this not apply to serial for each? Semantics are the same but the implementation is much easier.
Yaron: Serial for each is the same thing as a while.
Danny: Given that serial and parallel for each are not two separate activities, I'd like them to be consistent. We can add some use cases too.
Diane: Do you want to make an amendment?
Danny: I propose an amendment that applies the completion condition to both serial and parallel for each.
Ivana: I have no problem with this. Consider it a friendly amendment.
Satish: We’ll have to fix the language - there is no termination in serial.
Alex: Do we need to open a sub-issue?
Diane: Perhaps we should accept this as "Part B" of the proposal that we will vote on separately. 6.2 will not close until we vote on "Part B". Otherwise we have to open a sub-issue.
Satish: If Part A fails, B goes away. If Part A passes, Part B still may not pass.
Danny: I'd like to hear more opinions on Yuzo's question. If a branch completes and you know that the condition has been reached can you terminate everyone? What about if the condition can never be reached - can you recognize this and terminate everyone as well?
Satish: The goal is to complete the completion condition.
A new amendment arose out of this discussion. It was decided that this new amendment would be voted on as part of the original proposal:
"If upon completion of a directly enclosed activity, it can be determined that the completion condition can never be true the "bpws:completionConditionFailure" MUST be thrown by the parallel for each activity."
Ivana: I accept this as an unfriendly amendment.
Alex: I second
Diane: Any objections to this amendment?
No objections - amendment was passed.
Satish: If the parallel for each with a completion condition has its completion condition unsatisfied at the end of that activity then this fault must be thrown.
Danny: When you evaluate a completion condition to true then you shoot all outstanding processes
Danny, Ivana and Alex spent about 30 minutes discussing various options to make the amendment more general and understand how to calculate .
Diane: Read the friendly amendments based on feedback from Alex and Chris:

Amendment:

The completion condition feature can only be used for flow activities that exclusively contain scopes as their top level activities .

No second

Amendment:

Restrict the completion condition to apply to parallel for each only.

Seconded

Accepted as a friendly amendment

Amendment

the count of branches is calculated only once and won't

change as the result of the parallel for each execution.

Friendly amendment

Amendment

Fix language in section 13.4.4 Semantics of Activity Termination from:

"However, a termination handler cannot throw any fault. Even if an

uncaught fault occurs during its behavior, it is not rethrown to the

next enclosing scope. This is because the enclosing scope has already

either faulted or is in the process of being terminated, which is what

is causing the forced termination of the nested scope."

Add that the termination may be the outcome of early completion of parallel for each.

Friendly amendment.

Amendment: the term branches may be changed by the spec editing team to reconcile with parallel for each if they deem it appropriate.

Friendly amendment.

Amendment

"If upon completion of a directly enclosed activity, it can be determined that the completion condition can never be true the "bpws:completionConditionFailure" MUST be thrown by the parallel forEach activity."

Seconded

Passed no objection

Motion passed as amended y=8, n=3

Amendment

Apply completion condition to both serial and parallel for each.

Accept this suggestion as part b of the resolution for 6.2. We will vote on this at the next meeting if part a (Ivana’s motion with amendments as above) passes. If part a fails, this will no longer be relevant.

Diane: Any objection to adopting this proposal as amended?
Yaron: I object.
Diane: We will now vote.
In the room: 8 in favor, 3 opposed, 1 abstain
On the phone: 2 in favor, 0 opposed, 0 abstain
The proposal passed as amended. 6.2 is not totally closed yet. We must still vote on Part B.
Alex: We will vote on Part B next week.
Alex will send an email to the list indicating when we can discuss Part B of the proposal

Issue 120

There was a long discussion about the issues around multi-start. The discussion turned to whether or not we should remove it from the spec.
Yaron: Do we want to remove the restriction of a common correlation set? The only way it makes sense is if you have some extensions (such as opaque correlation sets) because the only way the process is going to work is if you "bend the rules" of BPEL a bit.
Satish: We are loose in allowing receives with no correlation sets.
Yaron: I disagree. If I have an incoming ping my process instance is ready to receive a ping message.
Satish: You can also receive a PO, Invoice, etc. It doesn’t matter.
Yaron: Its not necessarily loose its just that you are will to accept various incoming messages. I can’t imagine anyone having a common correlation set without some sort of BPEL extensions. Let’s leave the language as is and just close 120 with no changes to the spec.
Diane: Do we want to make a motion on 120?
Yaron: Lets leave 120 to Satish for now.

Issue 51

Alex: I am OK with the proposal in the PDF (see Sept 7 Seed Proposal PDF doc) - remove the third major bullet from the proposal and the corresponding section from the spec. I will accept this as a friendly amendment.
Alex: I make a motion
Charlton: Second.
Diane: Further discussion?
None.
Diane: Any objections to adopting this proposal as amended?
No objections, passed.

Issue 120.2

Danny: I summarized my opinions in yesterday's email.
Ivana: But its not really a resolution. Is there a resolution for 123?
Diane: We have a "conceptual resolution". Satish to write up the language.
Danny: Zero part messages is a degenerate case. How do you correlate a reply with an event handler?
Ivana: Without a solution for 123 we don’t have one for 120.
Diane: We have a "conceptual" resolution
Ivana: If there is a receive in a scope and no reply…
Danny: That is a different issue - its issue 221. When a process instance reaches the end of its behavior and one or more receive activities remain open, throw a "missing reply" fault.
Yaron: As soon as you can prove that there can never be a reply you have to throw the fault - this is hard to do. A good implementation should throw the fault as soon as possible. What is the response to the fault? Is it a design flaw? The process should be frozen as soon as possible. The spec doesn't necessarily go into detail here about how to handle the fault.
Yaron, Danny and Dieter discussed when the fault should be thrown and how the spec should document this.
Danny: If the process instance reaches the end of its behavior and a fault is thrown where does it go?
Yaron: Options for throwing the fauit:
Loose - sometime before the process ends
As soon as the message exchange and partner link go out of scope - by then you have to throw the fault
Throw the fault as soon as an activity begins an execution that is past the point of no return
Dieter: There are a large number of conditions in which we will end up with a missing reply.
Yaron: Not sure how we could write this up in spec language. This is an ugly, scary fault that will be difficult to implement.
Danny: So maybe the right thing to do is to just remove it.
Yaron: I'm willing to bet that most BPEL implementations will come with an option to turn this fault off.
Diane: We should write up a proposal to vote that can help drive the discussion.
Danny: I will send out a proposal to remove the "BPEL missing reply fault" and all the language associated with it.
Danny: This rescinds the resolution for Issue 50, we will then close it with no changes to the spec.

Issue 28

Yaron: Proposes a simpler subset of XPath to define join conditions.
Yaron will send out a proposal to close with no change to the spec (Assaf owns this issue and was not present at the F2F to discuss this issue.)

Issue 110

Yaron: The pattern attribute confuses request response with sync and async. I think the naming convention is confusing.
Yaron: Proposal - instruct editors to replace sync/async in reference to the pattern attribute with request/response.
Yaron: There are three points in this issue - I do not care anymore about renaming (this was the second point).
Yaron: We should also instruct the editors to put in text that restricts the pattern attribute to request/response for invokes.
Diane: We will send a proposal via email to vote on this issue.
Alex: The pattern attribute is schema-optional and can only be used for request/reply.

Danny: Motion to recess

Allen: Second

Meeting recessed at 6:05 PM PT

09/15

Meeting started at 9 AM

Satish Thatte took minutes

Issue 6

Diane: Issues 6 and its sub issues 6.x are independent. Closure of 6 does not imply closure of 6.x.
DieterK: propose to close issue 6 with no change to the spec. Satish seconded. Passed with no objection.

Issue 6.4

Alex: concurrency and expressions is a general problem. Do we want to say anything about it?
Alex has a current proposal posted. He will revisit and decide whether to propose a resolution based on the earlier and he will send mail to propose a resolution for vote in a week or so.

Issue 144

Yaron says this is housekeeping, to be dealt with when we reedit the spec.

Issue 174

Issue 88 doesn’t explicitly address this.
Yaron believes this has to be allowed and 88 language should be amended accordingly.
The sense of the room is that this will be allowed and Paco will be consulted and asked to make the proposal.
Paco agreed to make the change.
Dieter moved that multiple imports with the same namespace should be allowed
Yaron seconded.
No futher discussion.
Passed with no objection.
Editing team is asked to incorporate the change. 174 is closed.

Issue 184

Yaron and Satish believe this is another housekeeping issue.
Danny disagrees, and points out that there are “runnable” examples and explanatory examples.
Danny does not believe that there should be more than one or two “runnable” examples.
Yaron counters that even snippets should be self-contained that it is self-explanatory.
Monica asked that we should verify that the examples are semantically valid.

Issue 191

Yaron said this was legal.
Satish and Dieter pointed out that it was not since createInstance=yes is allowed on initial receives only.
Danny will research and restate.

Issue 193

Wait till Prasad is able to participate.

Issue 195

Yaron believes WS-I will solve.

Issue 197

Alex believes after 125 is closed this can be closed.

Issue 207

Yaron pointed out that many of these issues have been resolved by the resolution of 226.
Discussion to clarify why <compensate/> activity is confusing.
Need to review language around default fault and compensation handlers and the semantics of <compensate/> and make a proposal. Renaming <compensate/> can then be revisited.
Alex: I prefer renaming regardless of text. Compensation should be able to refer to the compensation activities attached to event handlers.
Danny: clarify directly enclosed scopes.
Dieter volunteered to write up the proposal.
The second example was resolved by 226.
The third example requires again clarification of both the meaning of directly nested scopes in themselves and in relationship to compensation behavior for the scope—compensation behavior only applies to the scopes nested in the main body of the scope.
Yaron: Example 4 (G) again seems to require clarification of which scopes can be refered to for compensation: scopes refered to by named compensation activity MUST exist in the body of the enclosing scope, and also that such naming references must be statically verified and if a dangling reference is found then the process be rejected. Also clarify that compensate activity can only be used in a fault environment.
Example 5 (J) is a repeat of the previous example.
Discussion about whether or not this example is illegal. The problem again was naming of <compensate/> activity.
Satish pointed out that <compensate/> runs default behavior for either fault or compensation depending on where it is called.
Yuzo and Danny gave examples which were clarified.

Issue 82.3.

Diane: do you want to propose a vote?
Rania: no, I want to give an update. Alex had raised several issues on the previous txt, the main one being that there were unspecified things in the definition of completion. I agree. We should not allow new links to be added to existing activities in the abstract process. As a side effect join conditions cannot be changed. We have not done a new writeup because we were waiting for input from Satish.
Diane: I wonder if we shouldn’t wait for a complete write-up before voting. Does anyone have any issues beyond the ones Rania has identified?
Alex: you may want change the word completion condition any more.
Rania: changes to the base language subset part seem to be OK,
Diane: if getVariableData still disallowed?
Alex: Both Rania and I believe that use of variables in expressions should be allowed.
Rania: I will create a new proposal.
Satish: We should stop defining completions in intentional terms and define them as syntactic constraints, specifically that adding structure around existing activities in an abstract process is not allowed. Changing a (explicit or implicit) join condition on an existing activity in an abstract process should not be allowed because it amounts to changing structure. I will work with Rania to craft this language.

Issue 82.2

Charleton described the work of the abstract process template profile group as described in the posted proposal.
Diane: Are there other parties interested in working on other abstract process profiles.
Monica: If they want to then they can create a new sub-issue.
Diane: I was suggesting the need for speed.
Alex: I don’t think there are many hairy issues here, so please give us feedback soon.

Issue 216

Alex: We had a directional vote on this and we need formal text.

Ivana took minutes starting at 11:00 AM PT

Issue 216

Discussion about appropriate wording for groups.
Danny is drawing an example:

<while>

<while

</scope A>

When we call compensate for A then we compensate groups.

Satish: Do we need a language for (default) compensation of nested groups? When you say compensate A, I would say that the whole group needs to be compensated independent of the structure of the group.
Danny: If we have the following example

<while>

<scope>

<while

</scope A>

Satish: Additional handling for nested groups is needed. Proposal for wording:

If there is a fault in the compensation handler normal behavior applies, and in addition all other instances that remain in the group are uninstalled. But we have to be clear what the group is.

Danny: But we assume a flat space, which is not. When we install compensation handler we never said that it is installed in a lexical scope.
Danny: Discussion about implementation details – there is a table of installed compensation handlers.
Satish: But as a group is stored.
Danny: But when we next time instantiate compensation handler it goes in the same table with name only. Compensation handlers are installed in scoped fashion. This is what Satish is saying but we do not spell that out anywhere.
Alex: We do not say how we scope the instantiations of a compensation handler. I agree with Satish, but there is just one way to interpret that.
Danny: Multiple implementations are possible, so we have to make that clear.
Satish: The only way that a scope can be repeatedly executed is that it is “scoped”. Bottom-line: Clarify the behavior of compensation for a scope that is executed repeatedly (within a scope).
Diane: We are not ready for closing 216.
Diane: Anyone who wants to volunteer for 216? This cannot be a group effort.
Satish: Dieter has pen on compensation handler.
Satish: We have to incorporate resolutions on all issues concerning compensation model as a single unit of work.

Issue 217

Alex: New description issue 217?
Yaron: New description should be as follows. The name of compensate activity is causing confusion. We need to clarify.
Yaron: I move that we open 217.
Danny: Second
Diane: Any objection? No. Opened.

Issue 218

Yaron: We do not have a proposal.
Diane: What can we do to have one?
Monica: You may want to send an email and ask people whether someone would like to work on that.
Alex: It is time to give people 1 week time to submit proposals.
Danny: 1 week is not realistic.
Diane: This is not new to people and we should have a deadline.
We did not discuss about a concrete deadline.

Issue 229

Danny: There is no forward reference to property aliases. I talked to Chris about that. The description text comes from Chris. Do we have to define property references in the same WSDL as property aliases? It could be ok. We get unconventional use of XML. We should either make it more conventional or have a comment on why it is unconventional.
Alex: Seconded
Alex: For the 2nd question: probably it makes sense to have property aliases as part of the process definition.
Ivana: Then they are not reusable.
Diane: Any objection to open the issue?
Satish: I am not disagreeing that there is a level of ambiguity here, but there are multiple ways to resolve that, and taking just one approach - maybe is not appropriate to dictate a particular approach.
Alex. We may say this is one way.
Satish: But we are doing normative work. In that way we dictate.
Danny: We may have a non-normative comment, to describe what the problem is. It is not important where it will go, but should be explained. I would like to discuss this possibility with Chris.
Diane: We can discuss this is more length next week.

Issue 222

Yaron: For example, we use WS-Addressing and it has a way to identify process. And message is delivered to the process but after that the process evaluates correlation and it ends with “no matching correlation”. Preferred solution is that the process cannot receive message.
Satish: You may have visible and invisible correlations and there is an “AND”. So if not all correlations are matched the process does not get message.
Yaron: First, we have to decide whether we want to open the issue. The second step is to propose a solution.
Yaron: Motion to open the issue
Danny: Second
Diane: Any objection? No
Yaron: Proposal. I move that we instruct editors to amend the specification that the message cannot be received if it does not match the stated correlation sets.
Alan: Second
Alex: The question is whether developer should handle the error in the same process instance?
Yaron: There are other examples of similar problems and we do not consider them as an exception case
Danny: It should be treated as out-of-band.
Satish: Could you repeat objection?
Alex: The question is whether developer should handle the error in the same process instance?
Satish: The language on correlation violation says that all correlations must be satisfied.
Danny: This is confusing text.

Danny is pointing to the text in the specification: “If the correlation set is already initiated and the initiate attribute is set to "no", the correlation consistency constraint MUST to be observed. If the constraint is violated, the standard fault bpws:correlationViolation MUST be thrown by a compliant implementation.”

Yaron: But there should be no fault.
Satish: Obviously that fault makes sense for outbound activities but not for inbound.
Danny: I can work on language -> see Diane’s notes for wording. Text is repeated 3 times. We may trust editors that they will incorporate needed changes.
Diane: More discussion on the proposed resolution?
Satish: This is just clarification.
Diane: Any objection?
No. Passed.

Issue 223

Yaron: It is sibling to other one but in the opposite direction. The correlation violation on outbound activities. If fault missingReply stays in the specification, then the process may react. Maybe we would like to wait and resolve issue 221 first and come back to this issue then.
Yaron: Motion to open
Danny: Second
Diane: Any objection?
No. Opened.

Wrap Up Discussion

Diane: We did almost all on our agenda, except the OASIS process.
Diane: I will go through the issue list and put all issues without owners on the agenda.
John explained the OASIS standardization process. John uploaded his presentation to the BPEL documents area (http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php).
Diane discussed the IPR transition process. A presentation on this is available (see BPEL decouments area - http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php).

Danny: Motion to adjourn

Allen: Second

Meeting adjourned at 12:55 PM PT