W3C home > Mailing lists > Public > public-ws-chor@w3.org > June 2005

Re: IMPORTANT: Re: Proposal for 1166

From: Monica J Martin <Monica.Martin@Sun.COM>
Date: Tue, 21 Jun 2005 12:03:50 -0700
To: Gary Brown <gary@pi4tech.com>
Cc: "'WS-Choreography List'" <public-ws-chor@w3.org>
Message-id: <42B86496.7010604@sun.com>


> Brown: Although we will probably not vote on this proposal until Nick 
> is back from vacation, I would like to get any obvious issues out of 
> the way asap. So if anyone has any feedback I would appreciate it - 
> especially comments on the topic of finalizing an active sub-choreo, 
> as this was not discussed at the f2f.

mm1: In business, not all forks will necessarily join.  However, if you 
want to be explicit about the conditions and results, the constraint may 
be preferred. Perhaps we should consider what other impacts may exist 
finalize to help guide the option chosen. Thanks.

>     ----- Original Message -----
>     *From:* Gary Brown <mailto:gary@pi4tech.com>
>     *To:* 'WS-Choreography List' <mailto:public-ws-chor@w3.org>
>     *Sent:* Wednesday, June 15, 2005 11:23 AM
>     *Subject:* Re: Proposal for 1166
>
>     One consequence not discussed in the proposal is if a finialize
>     activity is executed on a sub-choreography instance that is still
>     active. In my original proposal I suggested that this could also
>     be a join condition?
>      
>     The only other alternative is that it would be undefined, so (as
>     in other situations) it is the responsibility of the choreo
>     designer to ensure that the instance has completed using the
>     appropriate CDL functions?
>      
>     Which is the preferred option?
>      
>     Regards
>     Gary
>
>         ----- Original Message -----
>         *From:* Gary Brown <mailto:gary@pi4tech.com>
>         *To:* 'WS-Choreography List' <mailto:public-ws-chor@w3.org>
>         *Sent:* Tuesday, June 14, 2005 8:57 PM
>         *Subject:* Proposal for 1166
>
>         Hi
>          
>         Below is a proposal for 1166 based on the solution discussed
>         this afternoon at the f2f. If Nick has the opportunity to
>         review these changes, before vacation, then we may be able to
>         adopt them soon than planned.
>          
>         Any comments from other members would also be welcome.
>          
>         Regards
>         Gary
>          
>         =======================================
>          
>
>          
>
>         change:
>
>         <perform choreographyName="qname"
>
>         choreographyInstanceId="XPath-expression"? >
>
>         <bind name="ncname">
>
>         <this variable="XPath-expression" role="qname"/>
>
>         <free variable="XPath-expression" role="qname"/>
>
>         </bind>*
>
>         Choreography-Notation?
>
>         </perform>
>
>         to:
>
>         <perform choreographyName="qname"
>
>         choreographyInstanceId="XPath-expression"?
>
>         block="true|false"? >
>
>         <bind name="ncname">
>
>         <this variable="XPath-expression" role="qname"/>
>
>         <free variable="XPath-expression" role="qname"/>
>
>         </bind>*
>
>         Choreography-Notation?
>
>         </perform>
>
>          
>
>          
>
>         After the para that begins:
>
>         The OPTIONAL choreographyInstanceId attribute
>
>         insert:
>
>         The OPTIONAL block attribute is used to indicate whether the
>         performing choreography should wait for the performed
>         choreography to complete before the perform activity
>         completes. If the block attribute is set to true, then the
>         perform activity will wait for the performed choreography to
>         complete. If the block attribute is false, then the perform
>         activity will complete immediately following the enablement of
>         the performed choreography, causing the performed choreography
>         to be active concurrently with other activities following the
>         perform activity. The default for this optional attribute is
>         'true'. NOTE: For the purpose of clarity, any non-blocking
>         performed sub-choreographies, that have not completed prior to
>         the end of the performing choreography, will be automatically
>         completed upon the completion of the performing choreography.
>
>          
>
>          
>
>          
>
>         Section 2.4.3.1 CDL Functions
>
>          
>
>         xsd:boolean hasChoreographyCompleted(xsd:string choreoName,
>         xsd:string choreoInstanceId?)
>
>         Returns true if the performed choreography(s) associated with
>         the parameter 'choreoName' and OPTIONAL choreoInstanceId has a
>         status of completed (successfully or unsuccessfully). If the
>         optional choreoInstanceId is not specified then the function
>         will evaluate whether all performed choreographies, with the
>         supplied name, have completed. If the named choreography has
>         not been performed, prior to this function being called, then
>         it will return false.
>
>          
>
>         xsd:string getChoreographyStatus(xsd:string choreoName,
>         xsd:string choreoInstanceId?)
>
>         Returns the current status associated with the identified
>         choreography and OPTIONAL instance id. If the instance id is
>         not specified, then there MUST only be a single instance of
>         that performed choreography in the scope of the current
>         choreography that is checking the status. The values of the
>         status can be 'enabled', 'completed-successfully',
>         'completed-unsuccessfully' or 'closed'. The valid transitions
>         of the choreography status are outlined in the Choreography
>         Lifeline section [section number].
>
>          
>
>          
>
>          
>
>          
>          
>
Received on Tuesday, 21 June 2005 19:03:58 GMT

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