W3C home > Mailing lists > Public > public-ws-chor@w3.org > June 2003

Re: Partial executability/ determinism of a Chor description language

From: Monica J. Martin <monica.martin@sun.com>
Date: Sun, 01 Jun 2003 20:03:49 -0600
Message-ID: <3EDAB085.4050804@sun.com>
To: Ricky Ho <riho@cisco.com>
CC: "Burdett, David" <david.burdett@commerceone.com>, public-ws-chor@w3.org

Ricky Ho wrote:

> David, my comment embedded ....
>> <DB>Sadly there is difference between the real decision criteria and the
>> actual ones. Suppose you have a simple response which results in 
>> rejecting
>> an order if the goods ordered are "out-of-stock". Sounds OK yes? 
>> However the
>> seller may have a policy of always saying "out of stock" when stock 
>> levels
>> are less than 10 so that they can always meet the demands of an 
>> important
>> customer. The buyer should never know that the seller is making this 
>> type of
>> decision. Again separate the decision criteria from the results of the
>> decision and how it communicated.</DB>
> <RH>
> Nowhere have I said that the seller MUST expose his "PRIVATE DECISION" 
> to the buyer.  If this is a "PRIVATE DECISION", then it is up to the 
> seller to decide how much of his decision criteria he want to share 
> for the benefit of the buyer, purely from the performance optimization 
> perspective.
> In another scenario, the decision criteria may be a "CONTRACT" between 
> the buyer and seller.  In this case, one party can sue the other one 
> if the contract is breach.
> Now whether this contract should be in a separate document is a 
> different question.  I don't see why this contract cannot be also 
> specified in the choreography definition itself.  As Assaf point out, 
> this contract only applies at this particular step in this choreography.
> </RH>
>> <DB>Decisions can only be machine enforceable if there is one 
>> "authority"
>> that has the power to enforce. As soon as you have two (or more) 
>> independent
>> businesses, running separate systems, the power to enforce is 
>> removed. So
>> basically when more than one role is involved, decisions are
>> unenforceable.</DB>
> <RH>
> I disagree.  If the decision is a contract, then either party can 
> verify whether the other party has breach it (ie: it is 
> "enforceable").  Whether it is "human enforceable" or "machine 
> enforceable" depends on how the decision criteria is specified.  If it 
> is XPATH, then it is machine-enforceable.  Otherwise, it is 
> human-enforceable by having a person read through the message log.
> </RH>
>> On the other hand, do we have other situations that no single party owns
>> the decision.  Lets say I withdraw money from my bank account.  Then 
>> there
>> should be a common decision criteria (if I have sufficient fund in my
>> account, then the withdrawal must be successful).
>> <DB>Maybe, but suppose you are behind on your mortgage payments, the 
>> bank
>> (in its fine print) may have legal right to freeze your funds.</DB>
> <RH>
> In this case, then an additional decision criteria "MUST have good 
> credit history" should also be added.  The bank can keep adding more 
> criteria but it must be exposed to me. (as long as this decision 
> criteria is a "contract")
> </RH>
>> In other words, the
>> decision criteria is part of the contract between me and my bank in our
>> choreography.  It is certainly not a private or "one-party" decision.
>> <DB>I disagree the bank has complete control. Ultimately you cannot 
>> force
>> the bank to make a payment to you unless you take them to court to 
>> enforce
>> the agreement. Also, this would only work if you working within the 
>> terms of
>> the agreement.</DB>
> <RH>
> What do I show to the court unless the contract is well-specified ?  
> Why can't the choreography definition itself be the contract ?  Why a 
> separate document is needed ?
> </RH>
> mm1: The choreography definition should not be a contract, although it 
> may understand the contract when its parameters are expressed in logic 
> (whether in or referenced by the choreography definition,....we'll see).,
Received on Sunday, 1 June 2003 21:54:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:59 UTC