The working assumption here is that interoperability via an object request broker can be either synchronous or asynchronous and thus there are only two cases. Object request brokers do support a third mode of working called deferred synchronous where the invoking application fires off its message, carries on with its own work and claims the reply from the ORB some time later. This third mode of operation is outside the scope of the current standard.
3The initial assumption for early implementations of this specification is that the value of the process_definition_id parameter has been provided by a human agent. It may be that later on more sophisticated ways of ascertianing the value of this parameter might be attempted, but the emphasis at this time is to keep things simple.
4 Note that this is the id of the invoking process. If the invoking process is itself an invoked sub-process, the id used is that of the invoking sub-process, not that of its parent.
5 May not be known by source workflow engine
6 Where interoperability is inter-organisational, it may not be appropriate to pass user ids across organiastion boundaries.
7 The return values here are taken from [WfMC015]. There is a difference here with the WMFetchProcessInstanceStatesList operation defined in [WfMC1009] which makes no assumptions about what states a process instance can have.
8 Created but not yet started
9 Once started, processes can be in the active or suspended state until one way or another they are terminated.
10 Information repeated for each attribute value to be set.
11 Information repeated for each attribute value set.
12 A working assumption is that for efficiency reasons it should be possible to obtain sets of workflow relevant data in a single interaction.
13 Information repeated for each attribute value set.
14 Information repeated for each attribute value to be set.
15 Do we want to track failed attempts to abort a process instance in the audit data?
16There is a question about whether we need this operation/state. It can be argued that the states process competed and process aborted are sufficient. Comments please.
17 Repeated as required by Number of Process Instances field
18 Information repeated for each attribute value changed
There are thus two kinds of session - those bracketing batches of requests and batches of responses and those deliniating dialogues where the two workflow engines are "logged on" to one another.
 Only possible for atomic messaging scenarios - so the following text does not apply to workflow engines interoperating in batch mode.
21 It will be necessary to declare any implementation constraints on the set of state changes that are supported