OASIS WS-BPEL F2F Minutes
Table of Contents
Issue 169 discussion continues
Issue 226 continues
Wrap Up Discussion
Morning minutes taken by Danny van der Rijn.
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.
Yaron and I have been discussing on the email list. I added 2 small bits
of syntax that may address Yaron’s concerns.
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.
wouldn’t that be in a deployment descriptor?
by externalizing it to config, you lose portability, since configs aren’t
If you believe in web services contracts, then you are using them, you have
to assume that underlying infra is honoring them.
instead of saying “typically…” say something else. wordsmith. 1st
green para, 3rd green sentence. spec shouldn’t be saying
what would you suggest?
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.
they need to be compatible if they are known.
only if validate switch is on.
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.
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.
I see what you’re saying.
what if the assign says validate=yes? In that case, static analysis makes
a lot of sense. Static analysis error would be good.
are we trying to dictate what analysis can be done?
There are all kinds of constraints specified by the flag. We’ll get into
a black hole trying to specify them.
agree. make clear when can assume when vbls are valid.
are you allowed to reject the process?
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?
at this point, the less language we try to put in, the better.
we should edit 51 to make it clear. 51 should turn into a very clear
description of validation semantics.
in other words, we should be clear about the constraints. We assume for
inbounds, the contents are valid.
no we don’t
part of 160, processor may provide means to turn on or off message
I thought we were going to assume that they’re valid.
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
agree that we should minimize, but we should mention it.
not normative language.
MAY. that’s pretty weak already. agree that we should minimize
drop green text?
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.
in other words, when is the PSVI flag on?
we have differing expectations. In one dimension we are clear. Most of
the people won’t turn on the flag until a later point.
so what we’re really saying is that we need 2 switches (not suggesting
it), one for performance, one for
validate=no doesn’t mean that we’re doing something illegal.
since we say don’t validate, you can’t assume that it’s valid.
but “no” is the default
we’ve been talking for 25 minutes
we’re not going to vote today, but we need to edit spec to completely
downplay static analysis.
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.
let’s not talk about static analysis at all.
in terms of static analysis, we just have 2 sentences if we ignore green
text, back to original
why do I need the analysis language in the text there?
let’s park the issue.
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?
I would like to take this offline to understand the argument.
If half the group wants to take it offline, let’s keep it online.
First sentence (after update the third bullet)… is from the original spec
What is it trying to say? It’s not from the original spec.
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
goes back to original
if validate=no, can’t do validation.
goes back to major clarification of what does validate=no mean? No
validation at all? 2 switches?
paraphrase. Alex is unhappy with validate=no. Oracle is going to do
lots of extrapolation
next Alex will tell what BEA is doing
.. to do analysis of types to tell people that stuff won’t work. But
we’re making that impossible.
most likely I will agree to drop this, I just want to make sure there’s
nothing there that’s worth keeping. Especially
we have it if validate=yes
if underlying data type says it can’t do it, which wins?
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.
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.
all bets are off at runtime. static analysis is implementation issue. do
we still have mismatchedAssign error?
validate=no, no error at all.
some other error?
there’s already one there.
fine with potentially dropping bullet. but would like to reread this a
number of types.
summarizing: result is that there will be a friendly amendment to delete
the 3rd bullet of the proposal. How long do you want to have
to consider it?
Charleton is involved
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?
what about inbound data?
already language in spec that says that you can’t make any assumptions.
I would interpret this that it’s OK for an implementation to know how it
is configured, and apply static analysis on it.
so what are we doing on 160?
editor needs to put that language back in.
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
Are you asking the same question that’s in another issue? I.E what’s are
the semantics of an empty from literal?
do we always parse as XML?
let’s say so. Group: Q1 both examples are valid. All examples look
good. Issue probably no longer valid.
we need to clarify how we parse stuff within <literal>. Also need
to clarify what <literal/> means. (empty literal).
source of copy is empty -> illegal, so <literal/> shouldn’t be
empty. Should be treated as empty string.
may want to use this issue to fix amendment from 157. will give us
trouble when trying to assign to simple string variable.
I thought we put in language that allowed us to have a TII that has
we adopted amendment from Danny to make that certain case illegal. String
variable can’t be initialized to empty string.
consequence of what we’re talking about is that there’s no way to have a
simple type string variable that is empty.
we need to make an exception case.
you’ll figure it out.
125 todo list: <literal> is processed as XML. Is there a consensus
on what <literal/> means.
can’t separate issues; declaring that it’s an empty string in current spec
is just mean.
not comfortable with <literal/> being empty string.
didn’t want situation where copy can delete. This would do that.
that was bigger scope amendment that failed. Smaller scope amendment
disallows deleting of elements, but not text nodes.
we’re abusing InfoSet.
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.
I still don’t understand the fix, but I guess I’ll see it later.
Yuzo, since you had a proposal, do you want to write it up?
what does that mean for 125?
125 gets hijacked.
I propose that 120 and 120.1 be closed with no change to the spec
we still have a statement that if there are multiple initial receives that
there MUST be correlation.
do we still need that requirement?
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..
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?
yes, use it to throw away multistart requirement.
Are you proposing an amendment to the current proposal?
yes, but I need to look at the current spec before I state it.
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?
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?
from the eventHandler context.
why is this not relevant to all request/replies in event handlers?
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.
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.
that does much more than we’ve ever said for correlation on outbound
ping message is degenerate case. You can’t do request/response using a
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.
another related issue to bring up – 227 – parallel forEach has the same
215 as well.
either we think really carefully about how to connect receives and
I originally proposed that messageExchange be scoped
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.
it was 123. We should reopen it.
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.
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
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
but you’re using magic to do it.
if there’s no engine magic, then there’s a fault.
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.
you’re using magic in all 3 cases.
loses a bunch of conversation while he participates in the conversation..
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.
we’re over 30 minutes. Need a new minute-taker before we leave for
discussion for after lunch.
are we doing on 120.1? Reopen 123? I propose that after lunch we look
**** Break for lunch ****
Alex Yiu took minutes after lunch.
Should we re-open issue 123?
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.
Event Handler is a scope.
Event Handler does contain a scope as of Issue 204, which was resolved.
Similar to <invoke>, can we make <onEvent> itself of
Problem of not making <onEvent> itself a scope has a forward
do we need something special to identify some message variables are used
why we need to change style of syntax now?
we are adding piecewise ... very confusing.
are we agreeing on something?
We can separate the semantic and syntax of <onEvent>.
We may not want to argue so much on syntax issue. Some discussion on
whether <onEvent> is an activity.
<onEvent> is not an activity. We should not use XML schema to
dictate the activity.
Let's make a motion that resolve for Issue partially.
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."
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
questions on declaration of partnerLink, message-variables,
we are willing to going through attributes and elements.
if we go for Danny's proposal, we should go all in. Take all <scope>
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.
how about <sources> and <targets>?
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. "
asked about the status of this vote and which issue this vote is
Make a motion to rescind the resolution of Issue 123.
and Ivana both seconded the rescinding the resolution of Issue 123.
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.
asking how to proceed discussion
is there any problem caused by this proposal.
One side effect we can throw missReply fault earlier when the scope
of messageExchange declaration ends.
What would be the matching rule?
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
two messageExchange of the same name in two scopes used by <recieve>
and <reply> in different scope would trigger fault. Confirmed that
Go for the vote. Is there any objection? No objection. We pass this
I will volunteer writing up the formal proposal.
Propose to close issue 227 without changes since it will be handled by the
new resolution of Issue 123.
Go for vote. Any objection. No objection. It is passed.
Do we allow not using variables in a <receive> operation and etc for
No. we voted down on that design.
whether we want to apply the current draft directional proposal of 120.2
... to apply parallel forEach.
I don't see motivation to apply the design pattern to parallel forEach.
tried to keep track with agenda.
120 and 120.1 - Satish to think about proposal.
120 and 120.1 are about the multi-start situation.
presented the proposal. (issue-169.pdf) (Sept 12, 2005)
asked about why Yuzo prefers "all links evaluate to false".
Because links can cross scope.
Is link status more associated with the activity or the enclosing scope of
the other reason I like Yuzo's preferred proposal: it gives consistency.
The fault is relatively serious. It is not a business logic fault.
If we want to that consistent behavior, make it the scope isolated. It is
just like other cases.
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.
It is just like other parallel activity.
If we want to make it really predictable, we may want to make the
evalation order sequential instead of parallel.
We want to say something explicit here.
I prefer "All the remaining evaluate to false".
John E. started taking minutes at 3 PM PT
Links outside the scope will be propagated and inside doesn’t matter
(because the scope has faulted)
Not opposed to sequential order (as defined in Yuzo's "draft" PDF
Agreed to make this a formal proposal
Happy with Satish's proposal
Motion to define the order of evaluation?
Motion for sequential order
Part 1 is defined as Sequential in order of definitions in the source.
Part 2 is "defined as all the remaining evaluate to false".
Does this change the semantics? (Simon and Satish briefly discuss a
scenario, after which
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.
We cannot make it predictable, so people don't necessarily think about
false transition conditions
These are probably just bad process examples
This doesn't hurt users at all - what they are using now is completely
Predictability is probably not that critical
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
Only if it hasn't been evaluated yet. Two issues: which fault gets
thrown, and if something is true which one gets evaluated
If the transition condition is known, and you can evaluate a join activity
which can evaluate to false - who faults first?
This is an edge case.
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
Scope termination must be further clarified in the spec
How is this specific to the transition condisitions becoming false? Are
transition conditions evaluated atomically?
Chris' point seems to be that it seems strange that we don’t know in what
order faults will be evalutaed
Undeterministic due to parallelism
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
All transitions out of a scope which has not yet been evaluated become
false if the scope is faulted.
Part 3 is now moot because multiple errors cannot do this
What about the faulted link? It evaluates to false
There is no difference between a transition condition that faults and a
transition condition that is not evaluated.
added this as a clarification to Part 2 of the partial resolution for 169.
motioned to make this a proposal
Any objections to voting on this?
Perhaps we should just hand this proposal off to the spec editors and let
them add it to the spec
agreed that the wording in the proposal was strong enough to hand off to
the spec editing team:
Issue 169: Transition condition error handling
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
motioned that Issues 4, 6, 6.2 and 142 should all be closed with no
changes to the spec.
seconded the motion
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.
I partially agree - close 142 and 4 but am not sure about the others
These issues are unrelated
Issue 142 was specifically created to deal with the "threat" of
Issue 6 and 6.2
This is why I closed 6.1 early
Move to make an unfriendly amendment to close 142 and 4 with no change to
seconded the unfriendly amendment
Issue 6 is more complex than 142. If we close 142 due to complexity then
we should close 6 as well
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.
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
Satish and Alex did a lot of work on completion activities - its only
associated with Flow activities
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.
The issue is that Alex and I are working on a simplified version of 6.2
for tomorrow's discussion.
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?
We shouldn’t be discussing our work, just discussing issues.
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.
I suggest we all hear Ivana's and Alex's work tomorrow before including 6.2
in the issues to close.
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.
Do you want to make an amendment to 6.2?
uhhh (gestures to Ivana)
The amendment currently under discussion is for closing 142 and 6 only.
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.
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
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.
asked Ivana about timeboxing 6 and 6.2.
I wanted to have a productive discussion.
How many people are in favor of the amendment to close 142 and 4 with no
changes to the spec?
yes's in the room, 1 abstain on the phone
no's in the room, 1 no on the phone
motion passed - we're now discussing closing 142 and 4 with no changes to
yes's in the room, no yes's on the phone
no in the room, 2 no's on the phone
142 and 4 are now closed with no changes to the spec
Please mark 142 as revisitable in the spec.
Proposal to close with no change to the spec
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
We were told we should have a resolution to 51 and 157 before discussing
I thought Yaron was going to do some research on this.
According to the minutes, Yaron was going to provide some information on
I'd prefer not to close 11.
What is the relationship between 157, 51 and 11?
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?
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?
Compensation is like a continuation on the scope. I don’t think we can
claim this is unambiguously identified.
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
We've already discussed and passed this - see Issue 209
There is another issue. If we're in a while loop there will be multiple
compensation handlers that get called.
For while compensation handlers are called in reverse order.
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).
226 and 216 should be solved together since they are similar.
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.
Any subsequent attempts to call a fault handler would be a NO-OP
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.
The bottom line is that these are not real transactions. If the business
logic fails there is not standard way to handle it.
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.
Lets assume you are going to do 5 compensations serially how do you
compensate the other four?
There is a problem with the compensation - it’s a positive/negative way to
look at the issue
Perhaps this could be handled using a trap. This can be coded but its
Given the trap approach it seems like its at least possible to handle
sketched out a scenario on the whiteboard
executes 5 times (5 compensation handlers)
cases - one order matters, the other does not
the first compensation handler fails and order matters you've got to stop
(e.g. throw a standard fault)
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
the compensations are independent, go ahead and compensate them all
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.
Syntactically this means to run a compensator again
While this is possible its not easy to code this logic
What about parallel for each? All of the compensators may be active using
variables within a scope that has now faulted. Then what happens?
This is Issue 216 and its still open.
We can run the compensations in parallel. What then happens when one of
We should then cancel the others
If one of the compensators throws a fault to the parent, the other
compensators must be cancelled.
I don’t think we can re-invoke or compensate in any useful way in parallel
for-each - they should be NO-OPs
This sounds like a termination handler
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.
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.
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.
and Alex began reviewing several scenarios in an attempt to understand how
fault handlers should operate within a parallel scenario.
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.
There are always situations in which an automated decision is not
When does a termination handler on parallel instances get called?
Its not a termination issue. We need to freeze the process because the
situation is not decidable. We should introduce a standard fault called
Where do we catch it?
Where do we throw it?
We had this debate regarding 190.
We need to freeze the process as soon as possible - especially in the case
of deeply nested handlers.
This appears to be the only option available.
Not really-we could log something and then continue on.
If we don't freeze immediately we'll lose the context of the fault
There are two ways we can throw a fault - something goes wrong with the
underlying system or you've thrown the fault yourself
You're saying that usually what happens in a standard fault anyway.
We need to freeze a process asap
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.
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.
Not sure if we need this new standard fault. It is unexpected for a
compensator to throw a fault.
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.
Compensation is no longer possible at that point.
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.
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
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
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.
Multiple instances will be addressed by 216
made a motion based on Diane's notes, Danny seconded.
objections to accepting the motion as written above.
wording of the resolution needs additional wording added to it to
determine how to handle groups once 216 is completed.
motioned the updated wording. Charlton seconded.
updated proposal has been passed
Do we have a motion?
If we treat parallel for each as a unit this is easy.
216 doesn't seem to mention while, only for each.
While only deals with linear cases. For each is parallel, as does flow.
Flow is not a problem because of distinct names
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.
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
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.
The semantics of calling "compensate" is not stated - what does
"compensating for a fault inside a scope" mean?
were additional discussions about the draft motion that Diane typed up.
was a general consensus that we should table this motion for consideration
and additional discussion tomorrow.
Danny: Motion to recess
Meeting recessed at 6:30 PM PT.
Meeting started at 9 AM.
Allen Brooks took minutes.
Definition of a group of fault handlers "A compensation handler
instance group is defined to be all instantiations of a particular scope's
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.
A fault in a compensation handler will terminate the compensation handler
since the compensation handler cannon catch the fault.
Not clear from the current spec.
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.
But that language calls for compensation when faults are caught and that is
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
Effectively every compensation handler has a default fault handler that
kicks in when a fault happens, which compensates any contained scopes.
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
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.
You can put a guard around your compensation to distinguish between
unexpected faults and rethrow.
Compensation new semantics that are not part of other languages. We're
not used to how this works.
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
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.
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.
If there is no scope in a compensation handler none of these issues
exists. Also standard faults will not have this problem.
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.
What we want is standard BPEL termination semantics.
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.
But may not be the right way to handle them.
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.
What Yaron called the simplest option (no default fault handler,
compensation handlers not callable) is the right option.
In addition to default fault handler text should add recommendation to not
add compensation handlers inside fault handlers.
Compensation handlers and fault handlers are running inside scopes and so
scope should handle faults.
Fault handler not entirely in the scope in which it is defined or in the
scope from which it was called.
Do we want to start writing this up?
First we need to decide which option we want to include.
Its worse than we thought since there are implicit compensation handlers
as well as explicit compensation handlers.
What ever we do will hurt someone. Need to figure out which hurts less.
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
If the Compensation handler exits normally then the enclosed compensation
handlers are orphaned.
The argument is the same for fault handlers so they should behave in the
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.
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.
What to do with fault handlers? What to do when a fault handler faults?
What to do when a fault handler completes?
When a fault handler completes there should be no compensation handlers.
For consistency those compensation handlers become unreachable. This is
already the case.
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
I disagree. Fault handlers should be installed on parent scope.
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
Do we still need language about groups?
Language from current resolution is not broad enough.
Current model covers how termination works but descriptive language no
longer matches model.
Just need to describe fault handling behavior.
Need to have distinct paragraph describing termination behavior.
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)
of a compensation handler behaves analogously to the default termination
handler of a scope.
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
of how a fault handler exits, any contained compensation handlers are
a fault handler exits without throwing a fault, any contained compensation
handlers are uninstalled.
*** Break for lunch ***
moves that we pass the text elaborated in the hour before Satish seconds the
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.
We should sync up with 226
out the questions and sees if they have an answer to them.
yes, is answered
yes, is answered
intentionally left out for the editors, but the model and mechanism are defined
suggest to add the Diagram back to the spec
Well, we voted it out (issue 15?), now we need a vote to have it back, this is
not left to the editors
Correct. We need to vote it back in …
But only after it is ‘fixed up’
We will not close 226 BEFORE we have the actual language – general agreement
any other questions or comments – no comments
Any objections to adopting the partial resolution ? No objections – PASSED
Since we have Paco on the phone, we do Issue 88. Paco sent out revised text
explains some of the changes to the text. Paco also addresses some of the
comments that were sent as responses in email.
Monica’s Comment: I agree to add more normative language, i.e. “MUST NOT“
Comment by Alex, Chris and Prasad that we should discuss.
accepts Monica’s and Yaron’s comments as friendly amendments
I had comments associated with property aliases.
The issues is that Property Aliases are not directly referenced, they are not
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.
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
WSDL 2.0 is pretty clear on that. <reads out a part of section 4.2 of WSDL
Ok, it says “using import is a necessary condition”.
Why not state “if you use an element from a NS, that NS must be imported”?
Ok, any other questions?
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
draws a picture on a whiteboard>
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.
We have to allow that …
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
yes, but there is also point 2 from my mail. If and only if we make it
transitive, then we’re fine.
: Why are why banning transitivity when we get ambiguity like this?
To be clear on the import scenarios. You HAVE to import it directly
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.
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.
takes that as an friendly amendment>
Going back to transitive/non-transitive discussion.
I still fail to understand what the problem is: It’s just more labor to specify
I agree. But in terms of conflict resolution/conflict detection it should be
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?
Because the conflict only happens in the Process.
But there is no conflict unless you reference a foo/someNS:a directly
(referring to the example)
Let’s just go with the non-transitive approach
It’s an illusion that more import statements gives us more safety.
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>
makes an amendment: Make an import transitive.
seconds the amendment – No Discussion on the amendment
any other Discussion ? No more comments and discussion – we’ll vote <reads
out the text on the whiteboard> Any objections ?
objects to adopting the motion.
makes an amendment to remove the paragraph that states about the explicit
transitiveness, basically saying “leave this in the air”. Monica seconds the
takes this NOT as a friendly amendment.
further Discussion ? None. Any Objections?
3 in favor - 10 opposed – 1 abstains. – The amendment does not pass.
Paco, have we covered Prasad’s comments.(not NS-qualified imports)
Yes, it is consistent.
any objection to adopt the original motion as appended by the friendly
objections – Issue 88 passes.
Issue 6.2 is next, then an hour on the new OASIS process, and we move 82.2 to
John E. took minutes.
- 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
- 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
- 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
- Chris: This sounds like a parallel for each and
- 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
- 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
- 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
- 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
- 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
condition feature can only be used for flow activities that exclusively contain
scopes as their top level activities .
completion condition to apply to parallel for each only.
- 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
- 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
- Diane: We need a formal motion to amend and vote
- Ivana: I make a motion to propose this as a
- 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
- 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
- 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
- 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
- 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
- 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
- A new amendment arose out of this discussion. It
was decided that this new amendment would be voted on as part of the
- "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:
condition feature can only be used for flow activities that exclusively contain
scopes as their top level activities .
completion condition to apply to parallel for each only.
Accepted as a
the count of
branches is calculated only once and won't
change as the
result of the parallel for each execution.
Fix language in
section 13.4.4 Semantics of Activity Termination from:
termination handler cannot throw any fault. Even if an
occurs during its behavior, it is not rethrown to the
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.
Amendment: the term
branches may be changed by the spec editing team to reconcile with parallel for
each if they deem it appropriate.
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
Passed no objection
Motion passed as
amended y=8, n=3
condition to both serial and parallel for each.
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.
Danny: Motion to
Meeting recessed at
6:05 PM PT
Meeting started at 9 AM
Satish Thatte took minutes
Issues 6 and its sub issues 6.x are independent. Closure of 6 does not
imply closure of 6.x.
propose to close issue 6 with no change to the spec. Satish seconded.
Passed with no objection.
concurrency and expressions is a general problem. Do we want to say
anything about it?
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.
says this is housekeeping, to be dealt with when we reedit the spec.
88 doesn’t explicitly address this.
believes this has to be allowed and 88 language should be amended
sense of the room is that this will be allowed and Paco will be consulted
and asked to make the proposal.
agreed to make the change.
moved that multiple imports with the same namespace should be allowed
with no objection.
team is asked to incorporate the change. 174 is closed.
and Satish believe this is another housekeeping issue.
disagrees, and points out that there are “runnable” examples and
does not believe that there should be more than one or two “runnable”
counters that even snippets should be self-contained that it is
asked that we should verify that the examples are semantically valid.
said this was legal.
and Dieter pointed out that it was not since createInstance=yes is allowed
on initial receives only.
will research and restate.
till Prasad is able to participate.
believes WS-I will solve.
believes after 125 is closed this can be closed.
pointed out that many of these issues have been resolved by the resolution
to clarify why <compensate/> activity is confusing.
to review language around default fault and compensation handlers and the
semantics of <compensate/> and make a proposal. Renaming
<compensate/> can then be revisited.
I prefer renaming regardless of text. Compensation should be able to
refer to the compensation activities attached to event handlers.
clarify directly enclosed scopes.
volunteered to write up the proposal.
second example was resolved by 226.
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.
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.
5 (J) is a repeat of the previous example.
about whether or not this example is illegal. The problem again was
naming of <compensate/> activity.
pointed out that <compensate/> runs default behavior for either
fault or compensation depending on where it is called.
and Danny gave examples which were clarified.
do you want to propose a vote?
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.
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?
you may want change the word completion condition any more.
changes to the base language subset part seem to be OK,
if getVariableData still disallowed?
Both Rania and I believe that use of variables in expressions should be
I will create a new proposal.
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.
described the work of the abstract process template profile group as
described in the posted proposal.
Are there other parties interested in working on other abstract process
If they want to then they can create a new sub-issue.
I was suggesting the need for speed.
I don’t think there are many hairy issues here, so please give us feedback
- Alex: We had a directional vote on
this and we need formal text.
Ivana took minutes starting at 11:00 AM PT
about appropriate wording for groups.
is drawing an example:
When we call compensate for A then we compensate
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.
If we have the following example
Additional handling for nested groups is needed. Proposal for wording:
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.
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.
Discussion about implementation details – there is a table of installed
But as a group is stored.
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
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.
Multiple implementations are possible, so we have to make that clear.
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).
We are not ready for closing 216.
Anyone who wants to volunteer for 216? This cannot be a group effort.
Dieter has pen on compensation handler.
We have to incorporate resolutions on all issues concerning compensation
model as a single unit of work.
New description issue 217?
New description should be as follows. The name of compensate activity is
causing confusion. We need to clarify.
I move that we open 217.
Any objection? No. Opened.
We do not have a proposal.
What can we do to have one?
You may want to send an email and ask people whether someone would like to
work on that.
It is time to give people 1 week time to submit proposals.
1 week is not realistic.
This is not new to people and we should have a deadline.
did not discuss about a concrete deadline.
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.
For the 2nd question: probably it makes sense to have property aliases as
part of the process definition.
Then they are not reusable.
Any objection to open the issue?
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.
We may say this is one way.
But we are doing normative work. In that way we dictate.
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.
We can discuss this is more length next week.
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.
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.
First, we have to decide whether we want to open the issue. The second
step is to propose a solution.
Motion to open the issue
Any objection? No
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
The question is whether developer should handle the error in the same
There are other examples of similar problems and we do not consider them
as an exception case
It should be treated as out-of-band.
Could you repeat objection?
The question is whether developer should handle the error in the same
The language on correlation violation says that all correlations must be
This is confusing text.
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.”
But there should be no fault.
Obviously that fault makes sense for outbound activities but not for
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
More discussion on the proposed resolution?
This is just clarification.
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.
Motion to open
We did almost all on our agenda, except the OASIS process.
I will go through the issue list and put all issues without owners on the
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).
discussed the IPR transition process. A presentation on this is available
(see BPEL decouments area -
Danny: Motion to adjourn
Meeting adjourned at 12:55 PM PT