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

RE: Proposal for Issue 1166

From: Charlton Barreto <cbarreto@adobe.com>
Date: Mon, 25 Jul 2005 11:35:35 -0700
To: "'Gary Brown'" <gary@pi4tech.com>, "'wschor Group'" <public-ws-chor@w3.org>
Message-id: <0IK700H9D4ZBB1@mailsj-v1.corp.adobe.com>
Hi Gary,
 
Thanks - I think the first one is fairly straightforward to address....
Here's a draft of the language for this:
 
Section 5.3.1
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',
'closed' or 'unknown'. The valid transitions of the choreography status are
outlined in Section 5.7, Choreography Life-line.
 
Section 5.7 
A Choreography either not in an Enabled State, or in an otherwise
indeterminiate state, enters the Unknown State. '
 
The second one will require discussion for us to reach an agreement. My
thoughts are that all uncompleted subchoreos in a choreo completed due to
the completion condition should be unsuccessfully completed, and thus no
finalizer handlers would be installed. Forcing these uncompleted subchoreos
to complete, one must assume that they have not finished their tasks and
thus have not successfully completed. 
 
Cheers,
 
-Charlton.
--
Adobe Systems, Inc.
mailto:cbarreto@adobe.com
+1.408.536.4496p
 


  _____  

From: Gary Brown [mailto:gary@pi4tech.com] 
Sent: Monday, July 25, 2005 2:20 AM
To: Charlton Barreto; wschor Group
Subject: 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  <mailto:cbarreto@adobe.com> Barreto 
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

www.adobe.com
 logo.gif <applewebdata://E289E4FD-28CC-4DEF-8977-F22A1D605A57/logo.gif> 
Received on Monday, 25 July 2005 18:35:46 GMT

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