W3C home > Mailing lists > Public > public-ws-chor@w3.org > December 2004

Re: Reassertion of the request for clarification on short circuit evaluation

From: Gary Brown <gary@enigmatec.net>
Date: Fri, 10 Dec 2004 11:26:53 -0000
Message-ID: <007401c4deab$2a7c2750$4b00a8c0@LATTITUDEGary>
To: "Tony Fletcher" <tony_fletcher@btopenworld.com>, <public-ws-chor@w3.org>
MessageAgree that this needs to be clarified.


As to whether "short circuit evaluation" should be permitted or not, that is a difficult question. Given your example "Variable>100 AND hasDurationPassed(2hours)", you may want two outcomes:

- firstly to wait until the two hours is up and then evaluate. Although initially the value may be < 100, and so the expression would be false, at the two hour mark, this value may now be > 100, and therefore the expression is true i.e. the value has been updated in a concurrent activity.

- secondly, that you want to construct a complex expression where the two hour duration is actually only relevant if the value at the time the expression was first evaluated was > 100 - i.e. as you stated, this would cause the expression to fail immediately if value < 100

There is also another interpretation, based on the semantics that have been re-introduced as part of the most recent spec, which would say that - the guard conditon will block until "the value > 100 AND the two hours had expired", in other words, if the value changed to 101 after three hours, then the work unit would proceed.


Therefore I think this will have to be logged as a Last Call issue, as it is not a straightforward semantics to define.

Regards
Gary

----- Original Message ----- 
  From: Tony Fletcher 
  To: public-ws-chor@w3.org 
  Sent: Friday, December 10, 2004 10:40 AM
  Subject: Reassertion of the request for clarification on short circuit evaluation


  Dear Colleagues,

  I am aware that we have already discussed this issue, but on reflection I would like to re-assert my comment in clarifying with short circuit evaluation of Boolean conditions is mandated or prohibited.  The reason is given below followed by the comment.

  Short circuit evaluation of Boolean conditions does not alter the value of the condition but in CDL it can alter the time at which that condition evaluation becomes available, which in turn can alter the evolution of a choreography.  My concern is that if different endpoint projections make the opposite assumption then erroneous behaviour could result.

  Consider a Boolean condition of the form  Variable>100 AND hasDurationPassed(2hours)

  not exactly the correct syntax I am sure but hopefully you see the point.  With this condition as the value of a guard and block =true and assuming the variable value is available immediately and is such that Variable>100 is FALSE then if short circuit evaluation is mandated then the condition evaluates to FALSE immediately and the choreography moves on.  However, of short circuit evaluation is prohibited then the condition evaluates to FALSE only after two hours has elapsed - very different behaviour in time and as other interactions may also be time dependent we have to remember that CDL can yield descriptions with some dependency on time.

  Therefore: (!!)

  1)  Rationale: Short circuit evaluation of Boolean conditions should be explicitly allowed or disallowed so that different tools, endpoint projections, etc do not make contrary choices of how to evaluate.

   

  Add to section 2.4.3 Expressions (or elsewhere if a better place can be found):

   

  Boolean conditional expressions MUST use short circuit evaluation techniques whatever the setting of the block attribute.  That is once the value of a conditional expression can be evaluated and the result will no longer change if further variables become available or time based functions become true, the conditional expression returns its value.

   

  Note:  If it is thought this incorrect and we should not permit short circuit evaluation for some good reason then we should specifically prohibit it and add text similar to that above but stating MUST NOT instead.

   


  Best Regards     Tony
  A M Fletcher

  Cohesions  (TM)

  Business transaction management software for application coordination       www.choreology.com

  Choreology Ltd., 68 Lombard Street, London EC3V 9LJ     UK
  Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
  tony.fletcher@choreology.com     (Home: amfletcher@iee.org)
Received on Friday, 10 December 2004 11:27:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:15 GMT