- From: Ricky Ho <riho@cisco.com>
- Date: Fri, 30 May 2003 22:51:50 -0700
- To: "Burdett, David" <david.burdett@commerceone.com>
- Cc: public-ws-chor@w3.org
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> >In both cases, decision QName can be completely opaque and Yaron's >suggestion of using a text description of the decision completely fufill >the bare minimum requirement; "do-nothing" because nothing can be >done. But if we allow the decision QName be "optionally" has an associated >XPATH expression (which can be at another message binding level as David >suggest), then more automated checking can be done. In other words, I >suggest XPATH should be "optional", not required but also not excluded. ><DB>I also think that you need a Qname, but I think it should be the Qname >of the state which is the result of making the decision rather than the >QName that identifies *how* a decision is made.</DB> <RH> You don't need the QName to communicate the decision outcome. The outcome will be communicated from subsequent messages being exchanged. Let me give an example: if (qname:hasEnoughFund) then send fund-transfer-command else send reject message After the QName is defined, there are three options ..... Option 1 -- Nothing is binded to the QName. ================================= Do nothing because nothing can be done. Still meeting the "minimum requirement" as Assaf suggested. Option 2 -- A 30 page legal text document is binded to the QName ================================================= hasEnoughFund = "www.bank.com/legalAgreement.pdf" In this case, the contract is "human enforceable". I can trace through the message log to discover whether the bank has breach the contract. If so, I can printout the PDF file and bring that to the court. Option 3 -- An XPATH is binded to the QName ================================== hasEnoughFund = "/Request/@fundAmount < $BankAccount/@totalBalance" In this case, the contract is "machine enforceble". I can have an automated software that correlate the withdrawal rejection to the decision conditions and detect whether the bank has breach the contract. If so, I can printout my choreography (which also has the XPATH) and my message log to the court. </RH> Best regards, Ricky
Received on Saturday, 31 May 2003 01:52:37 UTC