09/13 – 09/15

Redmond, WA


Table of Contents

09/13. 2

Issue 51. 2

Issue 125. 6

Issue 120. 7

Issue 120.2. 8

Issue 123. 9

Issue 120.2. 11

Issue 169: 12

Issue 169 discussion continues. 12

Issue 142. 14

Issue 11. 17

Issue 226. 17

Issue 216. 21

09/14. 23

Issue 216/226. 23

Issue 226 continues. 26

Issue 6.2. 29

Issue 120. 36

Issue 51. 36

Issue 120.2. 36

Issue 28. 38

Issue 110. 38

09/15. 39

Issue 6. 39

Issue 6.4. 39

Issue 144. 39

Issue 174. 39

Issue 184. 39

Issue 191. 40

Issue 193. 40

Issue 195. 40

Issue 197. 40

Issue 207. 40

Issue 82.3. 41

Issue 82.2. 41

Issue 216. 42

Issue 216. 42

Issue 217. 43

Issue 218. 43

Issue 229. 44

Issue 222. 44

Issue 223. 45

Wrap Up Discussion. 46


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.

Issue 51

Issue 125

Issue 120

Issue 120.2

**** Break for lunch ****

Alex Yiu took minutes after lunch.

Issue 123

Issue 120.2

Issue 169:

John E. started taking minutes at 3 PM PT

Issue 169 discussion continues

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

Issue 11

 Issue 226

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.

 Issue 216

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


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


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

Danny: Motion to recess

Allen: Second

Meeting recessed at 6:30 PM PT. 



Meeting started at 9 AM. 

Allen Brooks took minutes.

Issue 216/226

·         Motion passed.

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

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

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

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

*** Break for lunch ***

Issue 226 continues


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

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

o        Yaron: We should sync up with 226

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

o        Q1: yes, is answered

o        Q2: yes, is answered

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

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

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

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

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

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

o        Diane: any other questions or comments – no comments

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

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

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

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

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

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

o        Chris: I had comments associated with property aliases.

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

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

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

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

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

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

o        Diane: Ok, any other questions?

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

o        <Danny draws a picture on a whiteboard>

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

o        Chris: We have to allow that …

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

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

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

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

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

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

o        <Paco takes that as an friendly amendment>

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

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

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

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

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

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

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

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

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

o        Alex makes an amendment: Make an import transitive.

o        Nobody seconds the amendment – No Discussion on the amendment

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

o        Alex objects to adopting the motion.

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

o        Paco takes this NOT as a friendly amendment.

o        Diane: further Discussion ? None.  Any Objections?

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

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

o        Paco: Yes, it is consistent.

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

o        No objections – Issue 88 passes.

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

John E. took minutes.

Issue 6.2


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


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



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

No second



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


Accepted as a friendly amendment



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

change as the result of the parallel for each execution.

Friendly amendment



Fix language in section 13.4.4 Semantics of Activity Termination from:

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

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

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

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

is causing the forced termination of the nested scope."

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

Friendly amendment.


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

Friendly amendment.



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


Passed no objection

Motion passed as amended y=8, n=3



Apply completion condition to both serial and parallel for each.

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


Issue 120

Issue 51

Issue 120.2

Issue 28

Issue 110


Danny: Motion to recess

Allen: Second

Meeting recessed at 6:05 PM PT


Meeting started at 9 AM

Satish Thatte took minutes

Issue 6

Issue 6.4

Issue 144

Issue 174

Issue 184

Issue 191

Issue 193

Issue 195

Issue 197

Issue 207


Issue 82.3.

Issue 82.2

Issue 216

Ivana took minutes starting at 11:00 AM PT

Issue 216



<scope A>

</scope A>


When we call compensate for A then we compensate groups.





<scope A>

</scope A>

Issue 217

Issue 218

Issue 229

Issue 222


Issue 223

Wrap Up Discussion

Danny: Motion to adjourn

Allen: Second

Meeting adjourned at 12:55 PM PT