RE: Partial executability/ determinism of a Chor description language

Assaf

Comments inline ...

David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Friday, May 30, 2003 2:21 PM
To: Burdett, David
Cc: 'Ricky Ho'; public-ws-chor@w3.org
Subject: Re: Partial executability/ determinism of a Chor description
language



><DB>I agree, but this type of "policy" information should be discovered in
>advance either by a human browsing the terms and conditions, or by
searching
>a registry that records this information. Although discovering it by
sending
>a trial message could work, it is not good practice. For example, what do
>you do if the sender does not accept "test" orders?</DB>
>  
>
Why human and not machine-processable? Let's assume we have the 
technology to evaluate some of these policies automatically. Why not use it?
<DB2>Having the technology is easy. The hard part is the standardization and
implemenation required before the technology can work. For example, for this
simple problem to work you need generally agreed definitions how "I do not
accept international orders" is described as well as have a registry
containing this information that is trusted - UDDI completely fails on the
trust issue.</DB2>

>I definitely cannot force my bank to do anything, but my bank advertises 
>a lot of its rules up-front. When I open an account or sign for a 
>service I get a booklet explaining a lot of rules. You can't withdraw 
>unless withdrawAmount<=balance is one of them. You will be charged $X 
>for returned check another one. Are we saying that the choreography 
>language should not in anyway reference such rules, even though they are 
>known and well defined?
><DB>Not quite. A choreography should only be interested in decisions that
>alter message flow. Also for reasons described earlier, I think you should
>separate the decision criteria (i.e. the how) from the decision result (the
>what). Choreography should only be concerned with the latter.</DB>
>  
>
We are mixing two things here.

The choreography should be concerned with the what which affects the 
message flow and I don't believe any of the examples I gave so far seems 
to contradict this rule.

The decision criteria should be separate from the choreography so it 
could apply to specific services and not others. And I don't believe any 
of the examples I gave contradict this rule either.

The decision criteria should be related to the choreography otherwise I 
have no clue where to apply it. The question then becomes how useful it 
is and how much we have to work to implement it. If it's not very useful 
and we have to do a lot of work to implement it, let's forget about it. 
But if it has some use and the requirements it places on the 
choreography incur no toll on the choreography per se, what's the problem?
<DB2>I think we are agreeing on this.</DB2>

arkin

>arkin
>
>Burdett, David wrote:
>  
>