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.