Re: [wsbpel] wspbel 5/1/2007: Draft Primer Comments for WS-BPEL v2.0

[Dieter Koenig1 <dieterkoenig@de.ibm.com>]

Hi Monica, thanks for the comments - I think the first one is now covered
as well.

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>                    Dieter Koenig1/Germany/IBM@IBMDE
             Sent by:                                                   cc
             Monica.Martin@Sun         Ron Ten-Hove                    
             .COM                      <Ronald.Ten-Hove@Sun.COM>, wsbpeltc
                                       <wsbpel@lists.oasis-open.org>   
                                                                   Subject
             02.05.2007 17:14          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.
>
>
>
>
>
>