Re: Partial executability/ determinism of a Chor description language

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)

In that case you would expose some of the rules regarding condition X, 
but not all of them. This is cleaner as far as the choreography 
definition goes, but a bit harder to do as far as the condition goes, so 
I prefer option 1. In either case the buyer side would look something like:

- case 1: receive accepted
- case 2: receive rejected

arkin


Jon Dart wrote:

>
> I suppose in this case you could (given the choreography definition, 
> which may contain XPath) simulate the effect of submitting an order, 
> without submitting it, and determine that it wouldn't be accepted. But 
> you couldn't really obtain assurance of acceptance, because there's no 
> guarantee all relevant processing criteria are visible to you (e.g. 
> the seller may reject your order because you have bad credit. You 
> don't know this until the seller does a credit query).
>
> --Jon

Received on Friday, 30 May 2003 15:39:13 UTC