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

Fwd: WorkUnit guard semantics issue

From: Steve Ross-Talbot <steve@enigmatec.net>
Date: Wed, 8 Dec 2004 15:07:48 +0000
Message-Id: <EC7094B5-492A-11D9-B668-000393D13C9A@enigmatec.net>
To: WS-Choreography List <public-ws-chor@w3.org>

Gentlepeople,

I wanted to present to you a history from 22nd Sept through to the  
current date of the WorkUnit with guards and blocking set to true.
In my previous email I alluded to all that follows. I do not think that  
this should prevent us from continuing on a present path but we
will need to rectify this matter during a last call period. We may as a  
group choose to include it in the LC issues page or we choose
to have it raised (and I am happy to do so) against the LC working  
draft when it has been done.

Best

Steve T


> Editors copy of 22nd Sept
> ref: http://www.w3.org/2002/ws/chor/edcopies/cdl/cdl.html
>
> 2.4.5 WorkUnits
> ......
> ? When the attribute block is set to "true" and one or more  
> Variable(s) are not available, then the Work Unit MUST block waiting  
> for the Variable information to become available. This attribute MUST  
> not be used in Exception Work Units. When the Variable information  
> specified by the guard condition become available then the guard  
> condition is evaluated:
> ?  If the guard condition evaluates to "false", then the Work Unit  
> matching fails and the Activity-Notation enclosed within the Work Unit  
> is skipped and the repetition condition even if specified is not  
> evaluated
> ? If the guard condition evaluates to "true", then the Work Unit is  
> matched and then the repetition condition, if specified, is evaluated  
> when the Variable information specified by the repetition condition  
> become available
> ? If the repetition condition evaluates to "true", then the Work Unit  
> is considered again for matching
> ? If the repetition condition evaluates to "false", then the Work Unit  
> is not considered again for matching
>
> Comments:
> Thus according to this draft if a WU has a guard with variables A, B  
> and C and condition "A > 1 && B != 6 && C < 5" and has blocking set to  
> "true" then when the variables A, B and C are available the condition  
> "A > 1 && B != 6 && C < 5" is evaluated. If the condition is false  
> because the information at A or B or C is such that this is so then  
> the Activity-Ntation within the WU is skipped.
>
> No examples in this version suggest otherwise.
>
>
> Working Draft 12th Oct
> Ref: http://www.w3.org/TR/2004/WD-ws-cdl-10-20041012/
>
> 2.4.5 WorkUnits
> .....
> ? When the attribute block is set to "true" and one or more  
> Variable(s) are not available, then the Work Unit MUST block waiting  
> for the Variable information to become available. This attribute MUST  
> not be used in Exception Work Units. When the Variable information  
> specified by the guard condition become available then the guard  
> condition is evaluated:
> ?  If the guard condition evaluates to "false", then the Work Unit  
> matching fails and the Activity-Notation enclosed within the Work Unit  
> is skipped and the repetition condition even if specified is not  
> evaluated
> ? If the guard condition evaluates to "true", then the Work Unit is  
> matched and then the repetition condition, if specified, is evaluated  
> when the Variable information specified by the repetition condition  
> become available
> ? If the repetition condition evaluates to "true", then the Work Unit  
> is considered again for matching
> ? If the repetition condition evaluates to "false", then the Work Unit  
> is not considered again for matching
>
> Comments:
> The 12 October working draft is unchanged at least in terms of the  
> guard semantics on WU's with blocking set to true.
>
> Editors Draft 11th November
> Ref:  
> http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/att-0055/ 
> cdl_v1-editors-nov11-2004-XML.pdf.tar.gz
>
> 2.4.6 WorkUnits
> .....
> The optional attribute block specifies whether the matching condition  
> relies on the Variable that is currently available, or whether the  
> Work Unit has to block waiting for the Variable to become available in  
> the future if it is not currently available. This attribute MUST  
> always be set to “false” in Exception Work Units. The default for this  
> attribute is set to “false”.
>
> .....
>
> • If the attribute block is set to "true" and one or more required  
> Variable(s) are not available, then the Work Unit MUST block. When the  
> required Variable information specified by the guard condition become  
> available and the guard condition evaluates to "true", then the Work  
> Unit is matched. If the repetition condition is specified, then it is  
> evaluated when the Work Unit completes successfully. Then, if the  
> required Variable information specified by the repetition condition is  
> available and the repetition condition evaluates to "true", the Work  
> Unit is considered again for matching. Otherwise, the Work Unit is not  
> considered again for matching
>
> Comments:
> In this draft the text has changed considerably but nothing in the  
> text suggests that the semantics are significantly different from the  
> previous working draft and editors draft listed above.
>
>
> Editors Draft 3rd December
> Ref:  
> http://lists.w3.org/Archives/Public/www-archive/2004Dec/att-0004/ 
> cdl_v1-editors-dec03-2004-XML-sent.pdf
>
> 2.4.6 WorkUnits
> .....
> The OPTIONAL attribute block specifies whether the Work Unit has to  
> block waiting for referenced Variables within the guard condition to  
> become available (if they are not already) and the guard condition to  
> evaluate to “true”. This attribute MUST always be set to “false” in  
> Exception Work Units. The default for this attribute is set to  
> “false”.
> .....
> If the attribute block is set to "true" and one or more required  
> Variable(s) are not available or the guard condition evaluates to  
> "false", then the Work Unit MUST block. When the required Variable  
> information specified by the guard condition become available and the  
> guard condition evaluates to "true", then the Work Unit is matched. If  
> the repetition condition is specified, then it is evaluated when the  
> Work Unit completes successfully. Then, if the required Variable  
> information specified by the repetition condition is available and the  
> repetition condition evaluates to "true", the Work Unit is considered  
> again for matching. Otherwise, the Work Unit is not considered again  
> for matching
>
>  Comments:
> This changes the semantics since it explicitly states that the guard  
> condition to evaluate to "true" in the first paragraph above as well  
> as or the guard condition evaluates to "false", then the Work Unit  
> MUST block in the second paragraph which was never stated before and  
> was in fact different all other references from 22nd Sept onwards to  
> 11th November.
>
>  Whilst we appreciate the need to make progress and we understand the  
> need to incorporate sensible semantics for timeouts we do not believe  
> that changing the semantics to accommodate the timeouts is a good  
> thing to be doing. It would be better to take a longer view.
>
> We do intend to raise this as an issue against the LC document when it  
> is published and we do not believe it has a major architectural  
> impact.
>
Received on Wednesday, 8 December 2004 15:17:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:06 UTC