OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]