Re: Partial executability/ determinism of a Chor description language

Assaf Arkin wrote:

>
> If you could receive assurance that the order will not be rejected we 
> could just write a choreography that has no 'rejected' message ;-)
>
> I suppose there are two ways to write the choreography.
>
> Option 1:
>
> - Case 1 (condition X): order rejected
> - Case 2 (condition Y): order rejected
> - Case 3 (otherwise): order accepted
>
> In this case some partners could expose information regarding 
> condition X that could allow you to decide definite cases where it 
> would be rejected, as in 'don't even bother sending this message'.  
> But there's also condition Y which is not exposed - it technically 
> cannot be exposed - e.g. rejected the order because the items are not 
> available, have just been recalled, or the seller's first name begins 
> with the letter 'A'. But there's an optimization you can do around 
> condition X.
>
> Option 2:
>
> - Case 1 (condition X): order rejected
> - Case 2 (otherwise): order accepted
>
> (or in reverse condition X accepts and otherwise rejects)

mm1: Assuming that only one condition determines the choreography step - 
which leads back to my question on business context.

Received on Sunday, 1 June 2003 21:02:08 UTC