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

Re: Proposal for Issue 1166

From: Monica J Martin <Monica.Martin@Sun.COM>
Date: Mon, 25 Jul 2005 11:39:01 -0700
To: Gary Brown <gary@pi4tech.com>, Charlton Barreto <cbarreto@adobe.com>
Cc: Charlton Barreto <cbarreto@adobe.com>, wschor Group <public-ws-chor@w3.org>
Message-id: <42E531C5.1010102@sun.com>

Gary Brown wrote:

> A couple of points, one minor, but the other probably requires 
> discussion on the next conf call:
>  
> 1) 'getChoreographyStatus' - I think this needs an additional 
> 'unknown' status value, in case the choreography is either not known, 
> or has not yet been enabled.

mm1: Unknown or unavailable (not the same however).

In addition for:
"/xsd:string getChoreographyStatus(xsd:string choreoName, xsd:string 
choreoInstanceId?)/ Returns the current status associated with the 
identified choreography and OPTIONAL /instanceId/. If the instanceId 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."

Change from: OPTIONAL /instanceId. /If the instanceId...
Change to: OPTIONAL /choreoInstanceId/. If the /choreoInstanceId...

/Question: Is there any need to specify that this constraint be handled 
by static analysis (single instance constraint). /
/

> 2) In the final paragraph, "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."
>  
> This text is ambiguious (my fault) in terms of how the sub-choreo is 
> completed, successfully or not. However, the same problem exists in 
> the choreo lifeline section. In section 5.7, when a choreo is 
> completed due to the "completion condition", it says about subchoreos:
> "all uncompleted enclosed Choreographies will automatically become 
> completed".
>  
> Does that mean successfully completed or unsuccessfully completed, 
> i.e. will there finalizer handlers be installed?

On this one, should we consider a minor revision:

    *Change from: After paragraph 9 of Section 6.7, 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, the perform activity will wait
    for the performed choreography to complete. <<If the block attribute
    is false, 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.

    *Change to: After paragraph 9 of Section 6.7, 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, the perform activity will wait
    for the performed choreography to complete. <<If the block attribute
    is false, the perform activity will complete immediately following
    the enablement of the performed choreography, which may cause 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.

Charlton, in line with Gary's question, we may need to discuss if any 
collision could occur and how we will resolve them (see <<..>>). Thanks.


>  
> Regards
> Gary
>
>     ----- Original Message -----
>     *From:* Charlton Barreto <mailto:cbarreto@adobe.com>
>     *To:* wschor Group <mailto:public-ws-chor@w3.org>
>     *Sent:* Saturday, July 23, 2005 12:43 AM
>     *Subject:* Proposal for Issue 1166
>
>     Hi all,
>
>     Here is the proposal for 1166:
>
>     *To Section 5.3.1, add the following function definitions*:
>     /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 (whether successfully or not). If the optional
>     /choreoInstanceId/ is not specified, 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, it will return false.
>
>      
>
>     /xsd:string getChoreographyStatus(xsd:string choreoName,
>     xsd:string choreoInstanceId?)/
>     Returns the current status associated with the identified
>     choreography and OPTIONAL /instanceId/. If the instanceId 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 Section 5.7, Choreography Life-line.
>
>     *In Section 6.3, in the syntax definition of the perform construct
>     after paragraph 4, update the definition to include the block
>     attribute as follows*:
>     <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>
>
>     *To paragraph 3 of Section 6.7, add*:
>     A finalize activity performed on uninstalled Finalizer Block(s)
>     will have no effect.
>
>     *After paragraph 9 of Section 6.7, 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, the perform activity will wait
>     for the performed choreography to complete. If the block attribute
>     is false, 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.
>
>     Please let me know if you have any questions....
>
>     Cheers,
>
>     -Charlton.
>     --
>     Charlton Barreto
>     P 1.408.536.4496
>     cbarreto@adobe.com <mailto:cbarreto@adobe.com>
>     www.adobe.com
>
Received on Monday, 25 July 2005 18:39:08 GMT

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