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

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