I think there is a coherence issue between the WFR 5 and 6 on Transition meta-class:
[5] Transitions outgoing pseudostates may not have a trigger
and
[6] An inital transition at the topmost level either has no trigger or it has trigger with the stereotype "create".

Initial transition is a specific case of transition outgoing a pseudostate. The WFR [6] puts then the WFR [5] in the wrong.

I propose then to have a single WFR and the following rewriting:

[5] The transition outgoing the initial pseudostate of statemachine root state either has no trigger or it has trigger with the stereotype "create". In all other case, transitions outgoing pseudostates may not have a trigger.

Yours,

Sébastien Gérard.

Summary: At the beginning of section 2.2, brief IDL description of WorkflowModel
module are described. In the description, "#include <TimeBase.idl>" is
expected compared with consolidated IDL. Is it dropped or not mentioned by
purpose?
Same things at section 2.15. Followings are expected.
#include <orb.idl>
#include <CosNotification.idl>
#include <CosTransactions.idl>
#include <CosLifeCycle.idl>
#include <ObjectIdentity.idl>

Fix IDL. In accordance with issue 2066 resolution.

Summary: In section 2.8.2 set_assignee() raises InvalidResource exception, and there
is an explanation about the exception, but it is not defined in section
2.8.1 and consolidated IDL.
In section 2.6.1 and 2.6.3, set_requester() raises CannotCha$B#n(BgeRequester
exception, but there is no explanation about the exception and it is not
defined in consolidated IDL.

Should these two exceptions be deleted or not?

Add missing IDL statements.

Summary: In section 2.4.5 and 3.4.1(consolidated IDL) exceptions regarding
ExecutionObject are defined but there are mismatches between them.

Operation |exceptions described in 2.4.5 |exceptions described in 3.4.1
----------------------------------------------------------------------------
----------
resume() |CannotResume, NotSuspended |CannotResume
suspend() |CannotSuspend, NotRunning |CannotSuspend,AlreadySuspended
terminate() |CannotStop, NotRunning | <----
abort() |CannotStop, NotRunning | <----
(cf. WfBase::BaseException is omitted)

What are the correct description?

Fix the inconsistencies.

Summary: Resolution:

Fix the IDL where it is different from section 2.4.4

Summary: Issue 3: Readonly attributes have set operations
Section 2.4.2 Attributes
Query: In the table in this section it is stated that key attribute is
readonly but in the IDL there is a set_key() operation. Set_key () is not
explained in this section.
Section 2.5.2 Attributes
Query 1: name attribute is specified as readonly. In IDL there is a
set_name() operation.
Query 2: description attribute is specified as readonly. In IDL there is a
set_description() operation.
Query 3: category attribute is specified as readonly. In IDL there is a
set_category() operation.
Query 4: version attribute is specified as readonly. In IDL there is a
set_version() operation.
Are all the above operations used only in initialization? Do they throw
BaseException if the above operations are requested after initialization?

resolved and closed

Summary: Issue 2: Propagation of state change
Section 2.4
Query: Is the propagation of state change of a WfProcess object down to
WfActivity objects or subprocesses is implementation and process definition
dependent?

resolved and closed

Summary: The resource protocol needs clarification. There should be no
relationship with a resource until there is an assignment. A potential
assignment could be presented to a large pool of potential resources, or
could be held by a resource manager until an assignment is determined.
Also, the diagram, Figure 2-2, does not show the release operation on
resource, but instead shows the resource sending a complete message to
the activity (backward). It also shows the resource sending an accept
message to the activity which does not appear to be defined for
activity.

resolved and closed

Summary: Section 2.8 WfEventAudit. The source association is presumably an
object reference to an activity or process. This may be okay in the
active environment, but I am concerned that this means all the process
and activity instances must be preserved as long as the events are
preserved. Is that reasonable?

resolved and closed

Summary: The create_process operation on WfProcessMgr (section 2.5.5) takes a
WfRequester as input. I would like to give the ProcessManager a chance to
reject a WfRequester by reasing an InvalidRequester exception. As a result, the
process would not signal events back to a Reqester; the requesting application
might decide not to use the created WfProcess.

Add an exception.

Summary: WfRequester, WfProcessManager, WfResource, WfEventAudit, WfAssignment and
WfExecutionObject all inherit from WfBase::BaseBusinessObject;
BaseBusinessObject inherits from CosTransactions::TransactionalObject,
CosObjectIdentity::IdentifiableObject, CosNotifyComm::StructuredPushSupplier
and CosLifeCycle::LifeCycleObject.

We had originally planned to provide a "lightweight" version of the
BaseBusinessObject and a Conformance Level hat allows for implementations of
the WfM Facility without dependencies on the CosServices. The solution proposed
in the original submission (bom/98-06-07) using #ifdefs was invalid and was
temporarily fixed in the Errata (bom/98-07-15) by dropping the simple version.

resolved and closed

Summary: Issue 8: When is the exception InvalidNames raised?
Section 2.15.2
QueryExceptions : exception InvalidNames{}.
Query: When is this exception raised? Is it only when invalid name value
list is provided as input for a set_name_in_expression operation of
BaseIterator?

closed, resolved

Summary: Issue 5: Completion of the related objects
Section 2.4.3 States
Query 1: In the table describing "how_closed" state set it is stated that "
it is assumed that all execution objects associated with that execution
object are completed when it enters this state". Is the assumption made
because there is some forced completion of execution objects related to the
execution object that enters the closed state?
Query 2: If the event occurs in situation that is assumed, then what needs
to be done? Is an exception raised?

rejected and closed

Summary: Issue 4: Operation name mismatch
Section 2.4.2 Attributes
Query: In context part of this section there is a set_context() operation.
In IDL it is given as set_process_context(). Which one is correct?
Section 2.5.2 Attributes
Query: In "Process signature information" part of this section on page 2-44
operations get_context_signature() and get_result_signature() are not in
IDL. Are they replaced by context_signature() and result_signature() which
are respectively present in IDL. Also the return values are different from
those in IDL.
Section 2.6 WfProcess
Query: In para 4 of "Process monitoring and control" part, Is get_result()
operation used instead of result() operation of WfProcess?
Section 2.7 WfActivity
Query: In para 1 of "Activity context and result" part, Is set_context used
instead of set_process_context?
Section 2.7.3
Relationships: process
Query: Should it be "container" instead of "process"?
Section 2.8.3
States: assignment_stateType assignment_status ( )
Query: Following correction is required in Spec and Errata, when it is
compared to consolidated IDL.

resolved and closed

Summary: Issue 1: meanings of "max_number"
Section 2.3.2
Relationships: WfProcessSequence get_sequence_performer (in long
max_number)
Query: Does this mean that it will return a list of "max_number" number of
WfProcess objects starting from zero position?
Section 2.7.3 and 2.9.3
Relationships: WfAssignmentSequence get_sequence_work_item( in long
max_number )
Query: Does this mean that it will return a list of "max_number" of
WfAssignment objects starting from zero position in the list?

resolved, issue closed

Summary: Section 3.2 (Proposed Compliance Points) should be refined by introducing a
compliance level for WfM Facility implementations that support WfProcessMgr,
WfProcess, WfActivity only.

resolved, see above

Summary: Issues raised from AB meeting in Helsinki, mostly editorial

Replace WfProcessMgr by the WfProcess that is being created as a source of the event.

Summary: In section 2.7 WfActivity in the sub-section called Activity realizations,
there is a discussion about Activities re-using a WfProcess.

This sections is very unclear to me. It appears to imply that a WfProcess
could be used to realize more than one WfActivity, but given that those 2
WfActivities could be executing in parallel and the context data is an
attribute of the Process (via inheritance from WfExecutionObject) this would
not seem possible.

Clarify that a WfProcess cannot be reused this way.

Summary: For consideration by the Workflow RTF:

We should discuss whether it makes sense to make WfEventAudit into a
"value-type" interface as defined by the ObjectsByValue specification.
EventAudits can only be accessed via their "sources" (WfExecutionObject) and
could be considered to be part of the state of these entities.

Dulicate of issue 2041 and therefore closed

Summary: The naming convention for operations is inconsistent and the attribute
and operation names and types in Figure 2-1 do not match the
specifications.

resolved, see above, issue closed

Summary: Figure 1-3, Workflow Reference Model, does not provide a reasonable
representation of the resource manager concept which is a generalization
of the work list concept. The associated text needs work also.

This overview material, as it is currently positioned in the proposal,
would probably not be part of the published specification since it is
under design rationale, which appears to be a justification for the
submission rather than the specification per se. It should be revised
to be an appropriate overview included in the final specification. Some
of the other material in Section 1 should also be adapted and included.

Duplicate of issue 2040 and therefore closed

Summary: Issue 7: Is exception InvalidData used for invalid set access?
Section 2.7.2 Attributes
Query: A ResultNotAvailable exception is raised when you have no access to
the result of an activity. There is no corresponding exception raised when
you try to set the result of such an activity. Is the exception InvalidData
meant for this purpose or for the purpose as stated in the specification?

resolved and closed

Summary: Issue 6: When WfActivity are created and activated
Section 2.7
Activity states:
Query: Implementation of WfM facility or WfProcess has to decide when to
create a WfActivity and when to activate WfActivity. Does this depend on
process definition?

rejected/closed

Thanks for your consideration in discussing with me an importante topic. I think that you are one of the few persons that are fighting to put this facility in the reality plan. And I would like to still discuss these topics with you in the future.
I think that the goal of the WMF DTF is to define a standard that could be possible the componentization and interoperability of a workflow management system. We also know that only the definition of the interfaces (syntactic interoperability) is not enough to the componentization. It is also needed to define the semantic of this interfaces at formal level (and sometimes is also needed to specify non-functional requirements as part of the contract but this is a future problem). The last is very dificult to be achieved but is needed to create an open standard.
But as a scientist I will to disagree with some points about your arguments in order to justify the stripping of the inheritance relationship between a WfActivity and a WfRequester. I think that you like to be a kind of Object-Oriented Jake Stripper

I found that the resolution text of issue 2041 had a problem.

In the text the following operation is added to WfExecutionObject interface.

boolean is_member_of_history(in WfExecutionObject member)
raises(WfBase::BaseException);

I think the argument "WfExecutionObject member" is strange because the
operation is named as "member of history".

Is it WfEventAudit ?

If it is WfEventAudit do we have to raise a RTF issue?

The UML diagram from the 1.2 version shows the aggregation
between WfProcess and WfActivity and the aggregation between
WfActivity and WfAssignment as aggregations with unidirectional
navigability (open diamond). These two aggregations should be
of typ[e composite aggregation with bidirectional navigability
(filled-in diamond).

Summary: Section 2.6.3 and the object model in Figure 2-1 state that there must be a
WfRequester associated with each WfProcess. Registering a Requester is useful
in scenarios where some entity is actually waiting for the process to complete.
There are several scenarios where this is not the case; for example when a
process is started in a chained sub-process scenario or when a process is
primarily started because of its "side-effects" (achieved by its Activities) ,
not to retrieve its results. In this case the status queries provided by
WfProcess are sufficient to allow an administrator to observe the WfProcess.
Making Requester mandatory implies that someone must keep a persistent object
around for a potentially long time even when there is no real use for it.

I propose to make the association between WfRequester and WfProcess optional
(i.e., cardinality of "requester" would be 0..1 instead of 1).

The spec says in section 2.4.5 that the state of WfExecutionObject can be
set to closed.

state.
Correct Figure 2-2 so that we can clearly understand the transition to
closed.completed state is permitted only from open.running state.

Summary: With respect to WfExecutionObject and WfEventAudit I am wondering if there
has been any consideration for loops in a workflow.

E.g. Would it be possible for the same WfExecutionObject to be executed
twice because there was a rework loop in the process definition ?

How would this impact the state diagram for WfExecutionObject ? There does
not appear to be any way to move "back" from closed to open.
How would this be handled by the WfEventAudit records ?

The UML diagram from the 1.2 version shows the aggregation
between WfProcess and WfActivity and the aggregation between
WfActivity and WfAssignment as aggregations with unidirectional
navigability (open diamond). These two aggregations should be
of typ[e composite aggregation with bidirectional navigability
(filled-in diamond).

Summary: Section 2 needs an overview. There should be discussion of how a
workflow process works, i.e., how the different elements come into play,
including (1) how a process gets initiated, (2) the invokation of a
sub-process and (3) the use of a sub-process to obtain a resource
assignment. We know this stuff, but others do not and we won"t always
be around to explain it. The diagram in Section 2.12 helps, but it is
buried in the back and needs a lot more explanation.

resolved and closed

Summary: Section 2.5 WfActivity. Activities need some attribute for defining
their order. I should be able to access activities chronologically in a
straightforward manner. Since there may be parallel threads within a
process, this cannot be a simple activity sequence number. One approach
would be to define a sequence number assigned by the process when each
activity is initiated to define the chronology. This gives me the
order, but still does not tell me which activity(s) completed for a
particular activity to start (dependencies). I could live with the
second issue (dependencies) left to the implementation and not exposed
at this time (although I think this is needed to be able to create a
meaningful display). I think the first (a sequence) is essential.

resolved and closed

Summary: Section 2.4 WfProcess. In most cases, when I am interested in an
active process, I am interested in the particular activity(s) that are
currently active, as opposed to those that are completed. Consequently,
I would provide two relationships to Activities: those that are active
and those that are completed. Without that, particularly with the last
relationship/iterator design I saw, there must be a considerable
exchange to get an iterator and then select the activities I am actually
interested in from what might be a very large set of completed
activities.

resolved and closed

Summary: Section 1.5.5 describes chained processes as supported. This seems to
me to be misleading, at least without further explanation. I believe
this is essentially enabled by (1) the fact that the invoking workflow
is not required to block until the invoked workflow completes and (2)
the fact that the invoking activity need not be the designated requester
for purposes of receiving completion or other events.

issue resolved and closed