RE: Definition of Choreography

Let me try to use a concrete example to illustrate using a modified FSN to 
represent a B2B public protocol.

This example use a simple purchase ordering process
1) A buyer place an order to the seller by invoking a synchronous SOAP call
2) The seller can either accepted it (by responding with an "accepted" 
message) or reject it (by responding with a "rejected" message) or throwing 
a SOAP fault, which will also transit to a rejected state

<choreography name="Purchase" startState="waitForPOState">
     <roleDefinition>
         <role name="buyer"/>
         <role name="seller">
             <portType name="Seller-PT"/>
         </role>
     </roleDefinition>
     <state name="waitForPOState">
         <event name="receivePOEvent" nextState="processingPOState">
             <request sender="buyer" receiver="seller" portType="Seller-PT" 
operation="submitOrder"/>
         </event>
     </state>
     <state name="processingPOState">
         <event name="acceptPOEvent" nextState="acceptedPOState">
             <reply sender="seller" receiver="buyer" portType="Seller-PT" 
operation="submitOrder">
                 <condition test="/body/submitOrderResponse/status = 
'accepted' "/>
             </reply>
         </event>
          <event name="rejectPOEvent" nextState="rejectedPOState">
             <reply sender="seller" receiver="buyer" portType="Seller-PT" 
operation="submitOrder"/>
                 <condition test="/body/submitOrderResponse/status = 
'rejected' "/>
             </reply>
         </event>
         <event name="faultPOEvent" nextState="rejectedPOState">
             <reply sender="seller" receiver="buyer" portType="Seller-PT" 
operation="submitOrder" faultName="InvalidPORequest" />
         </event>
     </state>
     <state name="acceptedPOState"/>
     <state name="rejectedPOState"/>
</choreography>


Here are some principles
1) Each communicating party's role and their associated PortType is defined 
upfront.
2) The choreography only defines what message exchanges are possible.  But 
it doesn't expose the decision criteria how a communication party choose 
one from those possibilities.
3) Every "event" must be an externally visible message exchange, which can 
be one party sending a request (request/reply or one-way) to the other 
party, or it can be one party sending a reply to a previous request (only 
in the request/reply case).
4) An event can be optionally qualified by a "condition", which is an XPATH 
boolean expression.
5) Each event will transit to ONE AND ONLY ONE next state.

Critics and counter suggestions are appreciated.

Rgds, Ricky