[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
Thanks for your responses, Dieter. > 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> > I think we are saying slightly different ways. You said that an abstract process may have "executable completions", which could be interpreted that an abstract process is NOT a subset. If you infer that each executable completion 'adds to the abstract process' then the abstract process IS a subset. I think we should be clear if the latter statement is consistent with yours Dieter, we should say that explicitly. Thanks. > 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]