WS-BPEL Consolidated F2F Minutes

November 14-16

Costa Mesa, CA USA (Filenet)

Nov 14, 2006 (morning)

Prepared by Alex Yiu

 

 

 

Nov 14, 2006 (afternoon)

Prepared by Martin Chapman

 

·         Mark motions, Dieter 2nds:

 

·         Insert a sentence to the end of Section 12.7.2 that states the interval for the <repeatEvery> is calculated when the parent scope starts. This doesn’t change when the clock starts, it just clarifies when the expression should be evaluated.

 

·         FROM:

o   If the <repeatEvery> expression is specified with either the <for> or the <until> expression, the first alarm is not fired until the time specified in the <for> or <until> expression expires; thereafter it is fired repeatedly at the interval specified by the <repeatEvery> expression. If the specified duration value for <repeatEvery> is zero or negative then the standard fault bpel:invalidExpressionValue MUST be thrown.

 

·         TO (bold text between *** has been inserted)

o   If the <repeatEvery> expression is specified with either the <for> or the <until> expression, the first alarm is not fired until the time specified in the <for> or <until> expression expires; thereafter it is fired repeatedly at the interval specified by the <repeatEvery> expression. *** The duration for the <repeatEvery> is calculated when the parent scope (the scope which directly encloses the event handler) starts. *** If the specified duration value for <repeatEvery> is zero or negative then the standard fault bpel:invalidExpressionValue MUST be thrown.

 

·         Danny proposes to amend by removing "(the scope which directly encloses the event handler) "

·         amendment accepted

 

·         TO:

o   If the <repeatEvery> expression is specified with either the <for> or the <until> expression, the first alarm is not fired until the time specified in the <for> or <until> expression expires; thereafter it is fired repeatedly at the interval specified by the <repeatEvery> expression. *** The duration for the <repeatEvery> is calculated when the parent scope starts. *** If the specified duration value for <repeatEvery> is zero or negative then the standard fault bpel:invalidExpressionValue MUST be thrown.

 

·         This will be a Substantive change.

 

·         No objections, issue closed

 

 

·         Proposed new issue from Monica:

 

·         When R18 was resolved another section was impacted but not addressed by those approved changes. See current text in Section 10.4:

·         (existing 10.4)

o   WS-BPEL treats faults based on abstract WSDL 1.1 operation definitions, without reference to binding details. This limits the ability of a WS-BPEL process to determine the information transmitted when faults are returned over a SOAP binding.

·         Reference: resolution of issue R18 (now correctly formatted in the issue list)
Submitter's proposal: Take an abbreviated approach for Section 10.4 and reference 10.3.

·         Change from:

o   WS-BPEL treats faults based on abstract WSDL 1.1 operation definitions, without reference to binding details. This limits the ability of a WS-BPEL process to determine the information transmitted when faults are returned over a SOAP binding.

·         Change to:

o   WS-BPEL treats faults based on abstract WSDL 1.1 operation definitions. This limits the ability of a WS-BPEL process to determine the information transmitted when faults are returned, such as for a SOAP binding (See Section 10.3, Invoking Web Services Operations - Invoke for fault treatment).

·         Monica motions to accept as an issue, and the proposal. Abbie 2nd.

·         Martin amends to close no change, 2nd Charlton.

·         Vote on the amendment: yes 2,  no 3. Fails.

·         No objections, so passed. R31 is closed

 

·         (note option c in the issue report from Alex not considered.)

·         After reviewing the example in section 15.2, I think there are some changes needed:

·         Syntax correction from:

o   <condition>"##opaque"</condition>

o   to:

o   <condition opaque="yes" />

·   Rectified opaque from spec usage in a few places: (because of another bug fix in other part of the spec)

o   <from opaque="yes" />

o   to

o   <opaqueFrom />

 

·   Alex Motions the above, 2nd Simon.

·   No objections, so passed. R32 closed.

 

·         Issue R40: From/To Extensibility

·   Description: Almost every WS-BPEL language element is extensible. The current specification defines a number of <from> and <to> element variants for the <copy> operation. The specification text in section 8.4. ("... MUST be one of the following variants: ...") excludes the extensibility of <from> and <to>. This is an unnecessary restriction. It forces every new variant of <copy> to be enclosed in an <extensibleAssignOperation> containing a new <copy> element which repeats the existing copy semantics in order to add different from-specs and to-specs.
Submitter's proposal: Make <from> and <to> elements extensible. That is, allow extension attributes and elements defined in other namespaces to appear within the <from> element and <to> element. The least invasive approach for the specification would be adding a new variant to the from-spec and to-spec. Note that the XML schema does not need to be changed as it already allows these extensions.

·   In 8.4., add a 6th variant to <from>:

·   <from from-attribute-of-another-namespace*>

·   from-element-of-another-namespace*</from>

·   and add a 5th variant to <to>:

·   <to to-attribute-of-another-namespace*>to-element-of-another-namespace*

·   </to>

 

·   After discussion a motion was made:

·   Danny motions, Abbie 2nds:

 

·   FROM: "the from-spec MUST be one of the following variants"

 

·   TO: "the from-spec MUST be one of the following variants, an extension of those variants or the special form of empty-variant"

 

·   Add the <from/> and <to/> options to each list

 

·   Add new sentence before “In addition to copy:”

 

 

·   Empty Variant[in bold]:  The sixth from-spec variant and fifth to-spec variant are included to explicitly show that from-spec and to-spec are extensible.  Note that if these variants are not extended, or the extensions are not understood, they will throw a bpel:selectionFailure fault.

 

·   Discussion:

·   Amendment from Deiter:

·   Empty Variant:  The sixth from-spec variant and fifth to-spec variant are included to explicitly show that from-spec and to-spec are extensible.  Note that if these variants are not extended, or the extensions are not understood, they will throw a bpel:selectionFailure fault.

 

·   Accepted as friendly

 

·   Amendment from Danny, accepted:

·   Empty variant: The sixth from-spec variant and fifth to-spec variant are included to explicitly show that from-spec and to-spec are extensible. Note that if these variants are not extended, or the extensions are not understood, they MUST behave as if they were an expression variant returning zero nodes.

 

·   Final motion:

 

·   Add the <from/> and <to/> options to each list

 

·   Add new sentence before “In addition to copy:”

 

·   Empty variant[in bold]: The sixth from-spec variant and fifth to-spec variant are included to explicitly show that from-spec and to-spec are extensible. Note that if these variants are not extended, or the extensions are not understood, they MUST behave as if they were an expression variant returning zero nodes.

 

·   No objections, passed, issue closed

 

·         Issue R27: Faults and Parallelism in Termination Handlers

·   From Dieter

·   Description: Consider the following examples of parallelism inside of termination handlers.

·   Example 1. Assume that a custom termination handler contains a parallel forEach activity or a flow activity. In either case, assume that multiple concurrent branches are active. If one branch faults, the specification does not tell whether the other branches are allowed to complete or terminated.

·   Example 2. Assume that a default termination handler that compensates a compensation handler instance group. If one compensation handler instance faults, the specification does not tell whether the other compensation handler instances are allowed to complete or terminated.
Submitter's proposal: Add the following to the end of section 12.6.:

·   "If a custom termination handler contains parallel activities and one of these activities propagates a fault then all concurrent activities in the termination handler MUST be terminated. Likewise, if a default termination handler compensates a compensation handler instance group and one of the compensation handler instances propagates a fault then the other compensation handler instances of the compensation handler instance group MUST be terminated."

 

·   Dieter motions to open issue, Abbie 2nd

·   No objections to  opening R27

 

 

·   Dieter motions, Charlton 2nds.

 

·   Add the following para  in 12.6, before last para “Forced termination is nested:

 

·   A fault in a termination handler MUST cause all running contained activities to be terminated.

 

·   Danny amends to(friendly)

 

·   A fault in a termination handler MUST cause all running contained activities to be terminated (see also section 12.4.4.3. Compensation within FCT-Handlers).

 

·   Final Motion:

·   A fault in a termination handler MUST cause all running contained activities to be terminated (see also section 12.4.4.3. Compensation within FCT-Handlers).

 

·   No objections, passed, r27 closed

 

·         Issue R26: Default Compensation Order Conflict

 

·   Danny motions to close no action, Martin 2nd.

 

·   Discussed happened.

·   Will come back to tomorrow.

 

·         Issue 28 and 41: IPR

o   Since IPR and Public review are separate process this is not a concern for PR.

o   Motion: Mike, 2nd Abbie. Close no action. Letter to this effect will be mailed out.

 

·         Meeting Recessed.

 

 

Nov 15, 2006 (morning)

Prepared by Allen Brookes

 

·         Dieter: (explains picture which will be sent out later), default compensation order may not happen even without termination handlers.

 

·         Options:

 

·         Dieter prefers option b

 

·         Diane: motion on the table for (a)

 

·         Alex: leans to option (a), add short paragraph to describe the problems

 

·         Dieter: that is the least we should do if we chose (a)

 

·         Dieter: what is your objection to (b)?

 

·         Alex: condition that identifies the change is not that clear, not enough time to explore all the details necessary.

 

·         Dieter: (b) adds familiar behavior since it is similar to what would happen with isolated scopes.

 

·         Danny: not really like an isolated scopes it just delays processing until enclosing scope is done.  I'm hesitant about making this change so late in the game.

 

·         Alex: should leave this for a later version.

 

·         Dieter: I don't want to give up on a global default compensation order.

 

·         Danny: we never really had it.

 

·         Danny: some vendors will provide these options and determine the right thing to do.  Standards shouldn't surprise

·         people.

 

·         Martin: should leave it with (a) add explanation for how to guaranty ordering.

 

·         Dieter: I can accept (a) with explanation of conflict scenarios.

 

·         Diane: Defer R26 until after lunch when we have Alex explanation.

 

·         Dieter: Options:

1)      Default remains "no", close without change

2)      Default globally changed to “Yes",  problem for scope-level partner links

3)      No default, not optimal for process-level partner links

4)      Different defaults, "yes' on process-level partner links, "no" on scope-level partner links.

 

·         Alex: leaning to (3)

 

·         Dieter: doesn't change things for process-level parter links

 

·         Alex: a default will be one more hurdle for users to jump in switching to BPEL 2.0

 

·         Mark: preference is to remove attribute.

 

o   drop the attribute

 

·         Mark: ok with (3)

 

·         Diane: do we have concrete proposals for any of the favored options?

 

·         Alex: no but we can do live editing, only need a small numbero of changes, update examples to show the values.

 

·         Mark: motion to remove default

 

·         Alex: second

 

·         Dieter: first time we have an attribute without default

 

·         Danny: no behavior associated with attribute, its all about deployment

 

·         (live editing)

·         section 6.2

·         Change: If the initializePartenerRole attribute is omitted then its value Must be treated as "no".

 

·         To: If the initializeParnerRole attribute is omitted then the Parnerrole MAY be initialized bya WS-BPEL processor.

 

·         Dieter: need to introduce attribute in examples

 

·         Danny: why?

 

·         Dieter: because it is nice to have an example

 

·         Mark: attribute doesn't tell deployer to set up WS-Addressing, not calling out need to set up bindings.

 

·         Dieter: not mandating using WS-Addressing

 

·         Martin: epr doesn't necessarily mean WS-Addressing epr

 

·         Mark: attribute means that deployer needs to initialize since process won't.  No way to indicate to the deployer that you need specific binding.  Original intent of attribute was to convey to deployer that some specific setup needed but in the case of  WS-Addressing value would be "no".  Not  sending a clear message to deployer.

 

·         Martin: not necessarily a problem, vendors will do what they need to do.

 

·         Danny: then why send only half the message?

 

·         Alex: bindings are out of  scope of the spec, try to indicate that part that  is in scope.

 

·         Mark: (from an old message) By putting on the flag the programmer is telling the deployment environment "I depend on the use of a transport that supplies the EPR of the sender of the message and further I depend on the engine being able to assign that EPR to the partnerRole, therefore this partnerLink MUST NOT be bound to a transport that does not have the previously described capability."

 

·         The flag doesn't do this now with the second bullet point.

 

·         Martin: why don't we delete the second bullet?  Answer to bullet 2 is vendor dependent.

 

·         Danny: (from the spec) If the initializePartnerRole attribute is set to "yes" then the WS-BPEL processor MUST initialize the EPR of the partnerRole before that EPR is first utilized by the WS-BPEL process

 

·         Doesn't tell whether process or processor is supposed to do this.  If we have this confusion so will others.

 

·         Starting to favor dropping the attribute.  Doesn't seem to do what we want.

 

·         Mark: value in sending a message, but the message is confusing.  If we can clean it up I can see keeping it but if not then we should drop it.

 

·         Diane: motion on the table is (3) no default,  Looks like the feeling is that it be changed to (5).

 

·         Martin and Dieter: dropping would be a bad idea.

 

·         Martin: problem is that there are 3 states, yes, no, and maybe.

 

·         Danny: yes says that process designer can rely on it being set. With maybe designer may be albe to rely on it so not portable.

 

·         Mark: no should mean that process will set the partner role, processor doesn't need to do anything.

 

·         Alex: dropping second bullet is fine.

 

·         Dieter: another thing is introducing a third value.

 

·         Mark: (old proposal for set of states)

·         Assign = process will init the plink through an assign

 

·         Addressing = process will rely on its bindings to init the plink through some reply-to header

 

·         Deployment = process will rely on its deployment to init the plink

 

·         Unspecified = process doesnt specify how a plink is initialized

 

·         Diane: what is the motion? (3), no default

 

·         Danny: move to choose option (5) drop the attribute

 

·         Diane: any objection?

 

·         Alex: object

 

·         Mark: accepted as friendly amendment

 

·         Diane: motion has been changed to drop the attribute

 

·         Diane: we are recinding some issues here.  We should be careful and explicity recind the issues.

 

·         Danny: all the options do this.

 

·         Monica: isses were 139, 139.1 and 96.1 (msg00047)

 

·         Alex: Paragraph added in Stutgart misclassifies the WS-Addressing case.

 

·         Dieter: so need to move the second bullet to yes side.

 

·         Alex: don't need the second bullet.

 

·         Diane: do we have an amendment to the motion?

 

·         Martin: remove the clarification paragraph added in Stutgart.

 

·         Danny: if "no" means you're going to initialize in the business logic then static analysis can verify this and the attribute is not needed.

 

·         Martin: no requires it to be initialized in the business logic, not just "allows" it.

 

·         Alex: we previously discussed whether static analysis was enough, but corner cases with flow creates ambiguity.

 

·         Diane: Motion on table is (5) drop the attribute.  We talked about whether this is recinding 139.1.  A lot of time was spent working on it.  We don't have that kind of time now so this is kind of risky.

 

·         Martin:  the only purpose of the attribute is for static analysis, check whether an assign is there when "no".

 

·         Danny: I don't think we want to mandate that type of static analysis.  This was contention when it was added and there is a glaring bug added in Stutgart.  If what we are talking about is not getting an uninitialized parter role by mistake, most cases can be caught by static analysis and fits the 80/20 case.

 

·         Alex: the attribute would be useful for static analysis.

 

·         Martin: two issues: whether initialized, and who initializes.  The more important one is who.

 

·         Danny:  More important than initialization is who touched it last.  If it gets set in the business process then initialization doesn't matter. Flag is only interesting in case when static analysis can't tell whether it has been initialized.

 

·         Martin: so issue is whether attribute is useful for this third case.

 

·         Diane: please go back and read the issues, discussion of 139, in Waldorf ...

 

·         Danny: so you want to eliminate runtime unitialized partner role?

 

·         Martin: no, know who's fault it is if it occurs.

 

·         Martin: propose to amend to remove the confusing text (paragraph added in Stutgart)

 

·         Abby: second

 

·         Chris: no default breaks 80/20 rule since in most cases it will be initialized by the environment, default should be true.

 

·         Alex: if not specified then let static analysis handle it.

 

·         Martin: then eliminate the attribute.

 

·         Martin: need separate discussions: whether to eliminate the text and what the default should be.  I think yes.

 

·         Chris: also need to change one of the examples that does dynamic assignment of partner link.

 

·         Martin: I have a pending motion, keep attribute, remove Stutgart text.

 

·         Diane: motion passed  9 yes, 5 no

 

·         Martin: motion to add "yes" as default

 

·         Danny: second

 

·         Diane: motion passed.  5 yes, 3 no

 

·         Danny: motion to amend to have no default, add text provisionally in, that default is partner role may be initialized by a ws-bpel processor.

 

·         Alex: second

 

·         Danny: in most cases static analysis can give you an answer so only require a value for attribute in the corner cases.

 

·         Diane:  motion passes 6 yes, 2 no

 

·         Diane: current motion is to delete Stutgart paragraph and add texst "the partner role MAY be initialized by a ws-bpel processor".

 

·         Diane: no objection, motion is passed.

 

 

·         Dieter: motion to open issue

 

·         Simon: second

 

·         Dieter: (explaining picture) optional XML elements (minoccurs=0), assign operation that copies some elements,

·         explicitly moving missing optional elements causing selection failure.  Alternative, check if element present.  

·         Proposal, add attribute to supress selection failure and make copy a no-op.

 

·         Simon: benefit is that it preserves anomicity of assign because all copies can be in the same assign.

 

·         Danny: we had long discussions about this type of thing before, decided that bpel is not a data manipulation language,

·         and decided to allow XSLT in assign as a compromise.  XSLT would allow this already, so I'm against this.

 

·         Martin:  common case, this is the quickest way to filter, I'm for it.

 

·         Diane: motion to open the issue passes, yes 8, no 2.

 

·         Alex: ok with proposal in general, what about if no data in to spec?

 

·         Simon: if no data in to but data in from then selection failure, if no data in both then no-op.

 

·         Dieter: motion to accept submitter's proposal.

 

·         Simon: second

 

·         Alex: amend last sentence to  "mote that if selectionFailure has  been suppressed on the from spec, the value of the

·         to spec is ignored.

 

·         Dieter: accepted as friendly amendment.

 

Nov 15, 2006 (afternoon)

Prepared by John Evdemon

 

·         Assign operation with multiple copy elements - move some elements but not all of them (meaning you cannot copy the parent element).  This means that some optional elements will be missing and may cause a selection failure.   We don't want to have to handle selection failures each time we want to copy values.

 

·         We can check to see if elements are present prior to copying:

<if>
      <condition> count($variable/optionalelement) = 1 </condition>
      <assign>
         <copy>
            <from> $variable/optionalelement </from>
            <to> ... </to>
         </copy>
      </assign>
   </if>

·         Proposal: 

 

·         Danny objected to opening this because he believed this could be accomplished with XSLT.   While this is true the proposal is makes it much easier to handle this situation.  The TC decided to open the issue.

 

·         Motion:

·         It was decided to table this discussion until later in the day

 

·         Proposed wording from Alex (apply to the end of section 12.5.2):

 

·         Danny suggested we should indicate that compensation may be surprising and supply an example as evidence. 

 

·         An illustration of the relevant scenario appears below:

http://static.flickr.com/117/298803905_da0ac7928f.jpg?v=0

 

·         This scenario appears to be in violation of Compensation Order Rule 1 (default compensation must respect the forward order of execution for the scopes being compensated, but only in so far as that order is mandated by the process definition).

·         Danny suggested adding a note at the end of the Rule 1 section to clarify this potential exception.

 

·         At the end of section 12.5.2, add the following paragraph:

"The default compensation order is initiated by default termination handlers and default fault handlers, and recursively carried forward by compensation handlers. The termination phase always precedes the fault handling phase (see section 12.6. Termination Handlers). This sequence must not create a conflict with the default compensation order of scopes that are in a control dependency relationship. If all of the following is true:

§  scope "S2" has a direct peer-scope dependency on scope "S1", caused by a scope "A" contained in "S1" and a scope "B" contained in "S2" where "B" has a control dependency on "A"

§  the scope-controlled set of activities of scope "S1" AND scope "S2" both contain at least one custom compensation handler                                                                                               then a WS-BPEL processor MUST execute these scopes as if "S2" had a control dependency on scope "S1".

 

·         Martin proposed moving this entire issue over the Primer and not addressing it in the spec at all.

 

·         A Straw Poll was taken (totals):

 

·         Alex made a motion to make the following clarification, Monica seconded:

 

·         Danny accepts this as a friendly amendment.

 

·         There were no objections to adopting this resolution for Issue 26.   Diane will send out a summarized version of this resolution to the TC.

 

·         Dieter and Simon made several proposals into IRC which were revised several times based upon feedback from the TC.  There was a very long discussion (well over 120 minutes) about how to write up the spec text.

 

·         Dieter summarized the options in the following table (this is apparently based upon their customer experiences with BPEL):

http://static.flickr.com/117/298805622_a04fcb06a6.jpg?v=0

 

·         The TC realized, after reviewing the table above, the name "suppressFromSelectionFailure" is misleading.    The TC decided to rename the attribute to "ignoreMissingFromData".     If this rename is approved it will affect R33.

 

·         Danny moved to close this issue with no change to the spec.   Monica seconded.  Danny indicated that this could be done with XSLT, avoiding the whole attribute naming/usage problem.

 

·         Simon objected to closing this issue, citing his experiences with customers that could use this feature (since they would have to write XSLT by hand otherwise).   Monica pointed out that we're adding a new feature that can be handled with existing functionality (XSLT).   Danny noted that this change will require a lot of people to change their BPEL implementations.     

 

·         Simon wants to amend Danny's motion to adopt resolution 33 based on the "spirit" of the table above (spec text will have to be drafted).  

 

·         Diane suggested we move on to R25 to give Simon and Dieter more time to think through R33 so that they can revise with a real amendment to include some draft spec text.  

 

·         Simon and Dieter agreed and we moved ahead to the next issue for discussion.

 

·         Motion:

·         In section 10.4, change

§  From:  If during the execution of a business process instance, two or more receive activities for the same partnerLink, operation and correlationSet(s) are simultaneously enabled, then the standard fault bpel:conflictingReceive MUST be thrown (note bpel:conflictingReceive differs from bpel:conflictingRequest, see section 10.4.1. Message Exchanges).

 

§  To: If during the execution of a business process instance, two or more receive activity instances for the same operation and the same values of partnerLink and correlationSet(s)are simultaneously enabled, then the standard fault bpel:conflictingReceive MUST be thrown (note bpel:conflictingReceive differs from bpel:conflictingRequest, see section 10.4.1. Message Exchanges).  

 

·         Possible amendment discussed:  

Pasted from <http://lists.oasis-open.org/archives/wsbpel/200611/msg00063.html>

 

·         Mark posted a potential amendment to the proposal:

 

·         Danny disagreed with the ambiguousReceive fault proposal.   

·         Danny and Martin recommended going back to the original spec text.

 

·         Martin made a motion to amend the yesterday's motion for this issue:

·         From: 

o   If during the execution of a business process instance, two or more receive activities for the same partnerLink, operation and correlationSet(s) are simultaneously enabled, then the standard fault bpel:conflictingReceive MUST be thrown (note bpel:conflictingReceive differs from bpel:conflictingRequest, see section 10.4.1. Message Exchanges).

 

·         To:

o   If during the execution of a business process instance, two or more receive activity instances for the same partnerLink, operation and correlationSet(s) are simultaneously enabled, then the standard fault bpel:conflictingReceive MUST be thrown (note bpel:conflictingReceive differs from bpel:conflictingRequest, see section 10.4.1. Message Exchanges).

 

·         There were no objections to the motion.   The proposal was amended.

 

·         The proposal was revised to:

 

·         There may be receive activity instances on an operation where the partnerLink and correlationSet(s) are different, yet indistinguishable to a WS-BPEL processor at runtime. In these cases, a WS-BPEL processor SHOULD throw a bpel:conflictingReceive fault.

 

·         No objections, proposal was amended.

 

·         No objections, the proposal was accepted.   R25 is now closed based upon the revised proposal. 

 

·         R25 is a substantive change due to the addition of SHOULD.

 

·         Revised description from previous (above):

The <copy> operation is a one-to-one replacement operation. If the optional ignoreMissingFromData attribute has the value of "yes" and the from-spec returns zero XML information items then the <copy> MUST be a "no-op"; no bpel:selectionFailure is thrown. In this case, the to-spec MUST not be evaluated. A bpel:selectionFailure MUST still be thrown in the following cases, even if the ignoreMissingFromData attribute has the value of "yes":

§  The from-spec selects multiple XML information items

§  The from-spec selects one XML information item and the to-spec does not select exactly one XML information item

 

If the ignoreMissingFromData attribute has the value of "no" this requires that both the from-spec and to-spec MUST select exactly one of the three information items described above. If the from-spec or to-spec do not select exactly one information item during execution, then the standard fault bpel:selectionFailure MUST be thrown. The following table illustrates the behavior of the ignoreMissingFromData attribute in the <copy> operation:

 

http://static.flickr.com/105/298817231_0300fe5349.jpg?v=0

 

 

 

·         Section 8.4:

The optional ignoreMissingFromData attribute of the <copy> construct is used to specify whether a bpel:selectionFailure standard fault is suppressed as specified in section 8.4.1. Selection Result of Copy Operations. The default value of the ignoreMissingFromData is "no".

 

·         Section 8.4.1 (revised para):

The <copy> operation is a one-to-one replacement operation. If the optional ignoreMissingFromData attribute has the value of "yes" and the from-spec returns zero XML information items then the <copy> MUST be a "no-op"; no bpel:selectionFailure is thrown. In this case, the to-spec MUST not be evaluated. A bpel:selectionFailure MUST still be thrown in the following cases, even if the ignoreMissingFromData attribute has the value of "yes":

 

If the ignoreMissingFromData attribute has the value of "no" this requires that both the from-spec and to-spec MUST select exactly one of the three information items described above. If the from-spec or to-spec do not select exactly one information item during execution, then the standard fault bpel:selectionFailure MUST be thrown. The following table illustrates the behavior of the ignoreMissingFromData attribute in the <copy> operation: 

http://static.flickr.com/105/298817231_0300fe5349.jpg?v=0

 

·         Any objections to adopting proposal for R33?   No objections.   Dieter and Simon's revised proposal is passed (R33 is now closed).  

·         R33 is a substantive change.

 

·         New issue proposed (R43): Restore Part C from Issue R32

·         The resolution to R32 had removed Part C from the original proposed resolution:

Simplify partnerLink usage: Potentially, we can simplify partnerLink usage (not a bug). The number of partnerLink used in this example is a bit too many. It makes the example harder to understand. I would suggest to combine some of them.

·         "ordering" + "orderingResponse" + "orderingConfirmation" => "ordering" (initializePartnerRole="no")

·         "shipper" + "shipperResponse" => "shipper" (initializePartnerRole="yes")

·         "invoiceProcessor" + "invoiceResponse" => "invoiceProcessor" (initializePartnerRole="no")

·         "shipperRequester" unchanged (initializePartnerRole="no")

Pasted from <http://www.choreology.com/external/WS_BPEL_review_issues_list.html>

 

Part C (above) will be used to open a new issue later this evening - R43 (Alex to submit this issue).

 

Administrative discussions:

·         Martin raised concerns about the IPR deadline in April 2007 and it possible impact on handling BPEL Errata.   The recommendation was to narrow the charter to focus only on Errata.

 

·         Martin moved to draft a straw poll to ask for input:

Set up a web ballot to ask:

o    If the TC should remain in place to allow for maintenance after approval as specified in our charter beyond April 2007. 

o    To do so requires transition to the new OASIS IPR policy.  Which of the options would your company support?

o    Are there any that your company would vote against.  Indicate which.      

 

 Meeting adjourned at 6:00 PM PT.

 

Nov 16, 2006

Prepared by Alex Yiu

 

 

·         Motion: Approve the latest version of spec text as the latest committee draft

o   Simon proposed the motion

o   Alex seconded the motion

o   No objection

 

·         Motion: To start the second public review draft

o   Abbie proposed the motion

o   Simon seconded the motion

o   No objection

 

 

Primer Discussion

 

Web ballot about the transition of IPR policy for maintenance/errata of this WS-BPEL 2.0 specification

 

Danny motioned to reopen the motion regarding public review

 

Charlton: Motion to adjourn

Alex seconded it.