[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] wspbel 5/1/2007: Draft Primer Comments for WS-BPEL v2.0
Hi Monica, I made updates in chapters 3-5 according to your comments - see also some answers below (marked <dk>). Kind Regards DK Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Vorsitzender des Aufsichtsrats: Johann Weihen Architect, Business Process Fax (office): (+49) 7031-16-4890 Geschäftsführung: Herbert Kircher Choreographer Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Sitz der Gesellschaft: Böblingen Schönaicher Strasse 220, 71032 Registergericht: Amtsgericht Böblingen, Germany Stuttgart, HRB 243294 "Monica J. Martin" <Monica.Martin@Su To n.COM> wsbpeltc Sent by: <wsbpel@lists.oasis-open.org>, Ron Monica.Martin@Sun Ten-Hove <Ronald.Ten-Hove@Sun.COM> .COM cc Subject 02.05.2007 03:13 [wsbpel] wspbel 5/1/2007: Draft Primer Comments for WS-BPEL v2.0 Related to: http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/23797/wsbpel-primer-draft.doc 1. Reference to design goals: There are goals we have yet to (or may not soon achieve). I suggest we state generally our overall design goals and then the result we have today or delete this section. For example, even though we have compensation, we do not address its relationship to transactionality - this is a separate discussion. 2. Section 2.3 jumps into differences with technical details too quickly. May wish to place this later in the primer (think about audience and then target where it should go). 3. Section 3.1: Abstract process may not be a subset (i.e. abstract process may result in many executable completions and then executable processes). It could go either way. Uncertain this statement is required. <dk>I do not agree on this one - all executable completions can only *add* to the abstract process - in this sense, "subset" is appropriate</dk> 4. Section 3.4.3: Change from: "The parallel variant is discussed further in the rest of this primer document". Change to: The parallel variant is discussed in more detail later. <dk>done</dk> 5. Section 3.4.4: Move this statement up where you introduce transition condition and talk about links (page 21~), "Transition conditions offer a mechanism to split the control flow based on certain conditions." <dk>revised text in the earlier section</dk> 6. Section 3.4.6: "As it can be seen in the example, a fault handler can have to types of children:..." to=>two <dk>done</dk> 7. Section 4.1: Introduce loop counter variable without explaining what it is. Same with suppressJoinFailure. May need to check the document overall to see if this is true in other cases and/or sections. <dk>added description to 3.4.4. and references in 4.1</dk> 8. Section 4.1.3 and 4.1.4: Explain what compensate and compensateScope are here somewhere (you talk about but don't differentiate). <dk>added explanation in 4.1.4</dk> 9. Section 4.2.5: May wish to state if message activities are ambiguous, we do have standard faults that handle. Here we state a case on how to alleviate. <dk>no change - the ambiguity resolved by messageExchanges is not subject of a standard fault - see static analysis rule SA00060</dk> 10. General: * Audience target: This is targeted to IT folks not business analysts. Look at how you jump into technical details quickly. Suggest you qualify the audience or concentrate on those that are most relevant to this document (system integrators, developers, etc). * Suggest to read specification first or used as a cross reference - suggest this be stated early in the document (particularly if you look at current Section 2.3 and the angle brackets showing up almost immediately). Will continue - stopped at top of Section 4.3. Thanks.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]