Just wanted to make a comment on the usage of 'time' within CDL, as the
different mechanisms do not seem very consistent. Therefore as part of the last
call process, I thought we may wish to review this and simplify the mechanism -
an outline proposal is provided at the end.

There are currently three places where time is used, the first two provide a
timeout scope mechanism, and the third appears to primarily be used as a 'sleep'
activity:

1) Interaction - time to complete

There is an element within the interaction called 'timeout' that can be used to
specify the time or duration when the interaction must complete by. If the
interaction has not completed, then the 'record' elements referenced by the
timeout will be performed. If one of these record elements has a
'causeException=true', then this will cause an exception, otherwise the
choreography would just continue past the interaction (with the relevant
variables set to indicate the failure).

2) Choreography - 'complete' expression

The complete expression on the 'choreography' element is used to prematurely
complete the choreography in a successful state. If the complete expression uses
a timeout CDL function, then a timeout can cause the choreography to be
completed. It does not seem valid that a choreography that has terminated due to
a timeout should be completed in a successful state + this mechanism does not
enable activities to be triggered to process the timeout, to enable the state to
indicate a failure.

3) Part of a WorkUnit guard condition

When used in a blocking guard condition, with the block attribute set to true,
the guard would block until the timeout has occurred. The semantics of this
construct is not representing a conditional statement, but is causing a 'sleep'
to occur prior to enabling the activities within the work unit.



Proposals:

The first two scenarios would be better represented using a 'timeout' scope
activity, which would contain the activities that were subject to the timeout.
If the activities within this scope do not complete within the defined time
period or duration, then these activities will be terminated and control will be
passed to a timeout handler associated with this scope.

In the first scenario described above, the 'record' elements that would have
been triggered by the timeout could be replaced by assign activities that would
achieve the same goal.

In the second scenario described above, this new mechanism would enable
activities to be performed when the timeout occurs, to determine in what state
the choreography should really complete.

The other benefit of this approach is that the set of activities within a
particular timeout scope can be wider than a single interaction, and less than a
whole choreography. Therefore it would be possible to define a timeout duraction
associated with a set of interactions - which in practice is more likely to be
the case.

The final part of the proposal is to create a new 'sleep' activity to replace
the use of the timeout functions within the workunit guard condition. This makes
the semantics of this activity very clear, and it also removes the requirement
for having the time based CDL functions - which will simplify the XPath expressions.


Regards
Gary