RE: Partial executability/ determinism of a Chor description language

Yaron's original point is that there shouldn't be any decision being 
exposed in choreography as XPATH.  I'm just thinking about some counter 
examples.

We probably talking about different things.  What you say is an agree-upon 
error code so that after the order is rejected, the buyer know the reason 
(in other words, the buyer knows the seller's private decision after the 
fact.  This is different from my example, what I say is the seller want to 
declare his decision upfront so that everyone will know before they send 
the message.  Isn't this a valid use case ?

Rgds, Ricky

At 09:45 PM 5/29/2003 -0700, Burdett, David wrote:
>Following on from this, in practice you would need to have error codes in 
>the return message that included one for "badlist" country. To realize 
>interoperability, the error codes that could be present in the message 
>data should be published in advance. In this case the sender should 
>already know that orders from a badlist country would not be accepted.
>
>I don't see what this has to do with choreography ... or am I missing 
>something.
>
>David
>-----Original Message-----
>From: Ricky Ho [mailto:riho@cisco.com]
>Sent: Wednesday, May 28, 2003 4:55 PM
>To: Yaron Y. Goland; public-ws-chor@w3.org
>Subject: RE: Partial executability/ determinism of a Chor description language
>
>Sorry if I give a bad example.  I just want to show in some case you 
>intentionally want to share your decision to the public.  How about this one ?
>I want to share every buyer my decision that if the destination address is 
>a badlist country, I won't accept the PO.
>
>Rgds, Ricky
>
>At 09:53 AM 5/28/2003 -0400, Yaron Y. Goland wrote:
>>Isn't the decision to require the use of a signature a configuration 
>>decision and therefore should be covered with a configuration mechanism 
>>and not in the high level workflow logic?
>>-----Original Message-----
>>From: public-ws-chor-request@w3.org 
>>[mailto:public-ws-chor-request@w3.org]On Behalf Of Ricky Ho
>>Sent: Wednesday, May 28, 2003 3:18 AM
>>To: Yaron Y. Goland; public-ws-chor@w3.org
>>Subject: RE: Partial executability/ determinism of a Chor description 
>>language
>>
>>I think there are 2 kinds of decision logic ...
>>
>>1) Private decision that I want to keep secret
>>E.g. If you send me a PO, I will either accept it or reject it.  But I 
>>don't want to share with you how I decide.
>>
>>2) Public decision that I want my partners to know about
>>E.g. If you send me a PO, I want to tell you that I will reject your PO 
>>message if you don't have a valid signature.
>>
>>I think WS-Chor should cover the later but not the former.  But I don't 
>>think expressing an XPATH necessary mean exposing private decision.  You 
>>may intentionally want to expose your decision criteria to your partners 
>>so they don't waste time to prepare something invalid.
>>
>>Best regards,
>>Ricky
>>
>>At 09:11 PM 5/27/2003 -0400, Yaron Y. Goland wrote:
>>>My personal preference is that nothing be said in the cDl about how the 
>>>message is to be processed. E.g. nothing is ever said about the contents 
>>>of the message and decisions made on those contents. This is exactly 
>>>what BPEL in general and BPEL abstract processes in particular are 
>>>intended for. They provide direct insight into how a participant makes a 
>>>decision at whatever level of detail one cares to share.
>>>The cDl on the other hand describes just the global behavior without 
>>>insight into a particular process. That is its key distinction with 
>>>regards to BPEL. If this group chooses to go down the path of providing 
>>>the type of message based execution decision described below inside of 
>>>the cDl then the working group will be taking a position that puts it 
>>>into direct competition with BPEL.
>>>There is nothing in the group's charter that says 'thou shalt avoid 
>>>competing with BPEL' and perhaps our best technical needs will be met by 
>>>such a competition. I personally do not believe so and have explained my 
>>>reasoning in my use case/requirements document. But if we do decide to 
>>>provide insight into the internals of a process's execution we should do 
>>>so with a clear understanding that we are talking a position in direct 
>>>competition with BPEL.
>>>     Thanks,
>>>         Yaron
>>>-----Original Message-----
>>>From: public-ws-chor-request@w3.org 
>>>[mailto:public-ws-chor-request@w3.org]On Behalf Of Fletcher, Tony
>>>Sent: Thursday, May 22, 2003 2:41 AM
>>>To: public-ws-chor@w3.org
>>>Subject: Partial executability/ determinism of a Chor description language
>>>Dear Colleagues,
>>>I would like to clarify in my own mind and continue a discussion o the 
>>>degree to which a Choreography description language (CDL) is 
>>>deterministic or 'executable'.  I think this issue links to previous 
>>>threads on the use of information from messages, or not.
>>>I think we all agree that a CDL will only give a very partial 
>>>description of the behaviour of any 'entity' playing a particular role 
>>>(and that you do need a full programming language such as Java or 
>>>C#  for any sort of 'complete' description.
>>>However, consider the following:
>>>Role A sends message 1 to role B
>>>Role B replies with message 2 to role A
>>>At this point there may now be say three different messages that A could 
>>>next send to B according to the CDL instance and given no other information.
>>>Now suppose that message 1 was an order message and message 2 an order 
>>>response with a critical information field that says 'accept' or 'reject'.
>>>The CDL could now say that role A can examine the incoming message 2 
>>>extract the semantic accept or reject and if reject then send message 3 
>>>else send message 4 or message 5 (means of determining which is not 
>>>shown in this CDL instance, but would be in the CPL for that role).
>>>Without being dependent on the precise syntax of messages, only some of 
>>>the semantic elements, I think that some people in this group would like 
>>>the above behaviour to be supported by the WS-Chor language and thus 
>>>support for this behaviour to be a requirement.
>>>Others seem to be arguing for no dependence on message content at all - 
>>>perhaps just the name of the message received(?).  Can we reach an 
>>>amicable consensus?
>>>Best Regards     Tony
>>>A M Fletcher
>>>Cohesions 1.0 (TM)
>>>Business transaction management software for application coordination
>>>Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
>>>Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0) 
>>>7801 948219
>>><mailto:tony.fletcher@choreology.com>tony.fletcher@choreology.com 
>>>(Home: amfletcher@iee.org)