Re: Proposal for Issue 1166

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.

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?

Regards
Gary
  ----- Original Message ----- 
  From: Charlton Barreto 
  To: wschor Group 
  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

  www.adobe.com