RE: Partial executability/ determinism of a Chor description la nguage

I don't disagree with you about putting an extra level of 
indirection.  What I'm focusing here is where that decision expression is 
ultimately "machine executable" at the Choreography level.  I think that 
should be OK which is different from Yaron's original point.

Rgds, Ricky

At 09:45 PM 5/29/2003 -0700, Burdett, David wrote:
>Ricky
>
>I think you are really defining the semantics and content of a particular 
>interchange. In this case, the results of your decision process would 
>probably end up as data content inside a PO Response document. The fact 
>that this information is included is a decision of the message/protocol 
>designer.
>
>Note however that you could have the identical choreography (i.e Buyer 
>sends a PO, Seller returns a PO Response) without including this information.
>
>This is a good example of why you want to separate the choreography 
>definition from the detailed message content definitions.
>
>David
>-----Original Message-----
>From: Ricky Ho [mailto:riho@cisco.com]
>Sent: Wednesday, May 28, 2003 12: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)