The LinkKind summary tables on pages 16-17 replicate the detailed tables included under each AbstractResource derived type, however, there are minor inconsistencies in that not all LinkKinds are presented in the summary.

Section 2.5.3 "Technical Note" of formal/00-05-03 contains the following statement: "In the absence of a value based mechanism to express the kind of links that can exist between resources, the following hierarchy shall be assumed in evaluation of the correspondence of a link kind during the execution of the expand operation on AbstractResource. Non shaded blocks indicate abstract link kind values; whereas, shaded blocks indicate concrete link kinds". In order to properly declare inheritance structure of Links it recommended that a Link valuetype be defined as a replacement to the existing Link struct.

The definition of BaseBusinessObject declares itself as an event publisher
for objects typically exposed within client applications presenting a
desktops and associated workspaces. If a client is maintaining a cache, the
client, following disconnection from and reconnection to an event channel
cannot establish if its internal cache is consistent with a source. As such
a client is obliged to rebuild a cache following any disconnection from the
event supplier creating an unacceptable performance degradation. Operations
are require to expose creation and modification timestamps related to the
event producer enabling client verification of creation and last
modification dates.

Task Structured Event Table on page 33 contains a reference to an event named "process_state" which is declares as an event exposing the state of Task. This event should be renamed to "task_state" as process and task state are independent according to the definition on page 31.

The specification of Task under section 2.2.1 identifies and distinguishes between Independent and Dependent Tasks and distinguishes between the behaviour expected from data centric resources as distinct from process centric resources. Furthermore the specification implies that the state of a Task is a function of the state of the processor in combination with the state of used resources (data state). Under the specification the processor argument to a Task is defined as an AbastractResource, however, an AbstractResource does not provide semantics supporting notions of process oriented state or notions dealing with dependence or independence relative to an associated task (other then task to processor relationships). For interoperability between different domains an abstract processor interface is required which exposes as a minimum (a) a distinction between processors that control Task state as distinct from processors that are independent of Task state, (b) semantics enabling propagation of processor state to a associated Task, (c) interfaces enabling to interoperable location, instantiation and activation of a processes, and (d) semantics supporting the association of the role of consumed and produced resource relative to a processor (e.g. ability to distinguish two consumed workspace supplied as consumed resources to a "copy" processor where one resource is the workspace to be copied and the second workspace is the destination workspace).

The specification of BaseBusinessObject includes inheritance of the
CosNotifyComm::StructuredPushConsumer and StructuredPushSupplier interfaces.
The semantics of StructuredPushSupplier implies association to a single
StructuredProxyPushConsumer, however, the BaseBusinessObject interface is
intended to support multiple concurrent consumers from potentially different
business domains without mandating nor excluding the use of Notification
channels as an implementation mechanisms. To enable the documented
behaviour an explicit factory operation is required through which a
StructuredPushSupplier reference can be exposed for a given consumer.

The Task and Session Specification defines a "contains" relationship between
a Workspace and AbstractResources contained by the workspace. An
AbstractResources may be contained within many Workspaces and Workspaces are
themselves AbstractResources. However, the semantics of "contains" with
respect to strong or weak aggregation are ambiguous. Achievement of
consistent behaviour of lifecycle operations (remove, copy and move) across
implementations requires explicit distinction between strong containment as
opposed to weak containment. Strong containment is required in order to
associate a resource with 0 to 1 principal workspace. Under strong
containment, the removal of a containing workspace implies the removal of
strongly contained resources. Under weak containment the removal of a
containing workspace implies the removal of "contained_by" relationships
held by contained resources towards the workspace. Under strong containment,
it should be illegal for a resource to strongly contain a resource it is
already strongly contained by.

The AbstractResource interface contains an operation called "expand" which
enables client applications to access relationships between resources.
Invocation of expand returns a sequence of iterator instances representing
the extent of a set of relationships, however, the iterator interface does
not expose the size of the extent. This restricts the ability of interactive
client applications dealing with navigation and graphic presentation of
relationship extents.

The LinkKind table for Task on page 32 does not define the abstract link "uses".

Summary: AbstractResource contains the declaration of the exception NotRemoved. This exception is
not used in the remainder of the interfaces.
Remove exception declaration.

resolved and closed

Summary: AbstractResource does not have operations required to notify it of the association of a Task
as producer. Operations are required on AbstractResource to set, get, and change
producer.

resolved and closed

Summary: AbstractResource references the structural feature bound_to with the type Usage, however,
the operations refer to Tasks as the type.
Replace Usage with Task.

resolved and closed

Summary: Attribute key serves to provide unique identification. This is duplicating functionality of the
inherited IdentifiableObject semantics.
Propose removal of the key attribute and retraction of key arguments under the
create_task, create_workspace, and create_subworkspace operations.

resolved and closed

Summary: The semantics of the filter argument to the list_history operation are undefined.
Nothing proposed at this stage.

closed and resolved

Summary: AbstractResource references the structural feature is_an with the type Containment,
however, the operations refer to Workspaces as the type.
Replace Containment with Workspace.

resolved and closed

Summary: No operations are provided for the removal of a produces association between a Task and
a AbstractResource produced by a Task (required on termination of the task).
Add the operation to the Task interface.
void remove_produced( in AbstractResource resource );
Note… additional operations are required on AbstractResource concerning the produces
association (refer issue 19, AbstractResource key).

closed and resolved

Summary: The operation add_consumer and add_producer are operations through which consumed
and produced resources may be associated with a Task. Semantically, the operations are
not adding “consumers” or “producers”, instead they are adding “consumed” and
“produced” resources.
Change the name of the operations to add_consumed and add_produced.

closed and resolved

Summary: Workspace and Task both contain the operation oneway void resource_event (in
ResourceEvent event) These declarations prevent the possibility of a developer
constructing an interface that inherits from both Task and Workspace. Secondly, the
definition of ResourceEvent is inconsistent with the currently adopted CosNotification
definition of a structured event. Thirdly, the specification does not define an interoperable
mechanisms through which events are propagated to targets (other than a reference to an
underlying event service).

resolved and closed

Summary: Task state references state_set which is a CDL keyword and should be removed.
Remove CDL state_set references.

Remove CDL state_set references.

Summary: Task structural feature list references a consumer feature and equates the type to Usage.

Updating of text in accordance with the exposed LinkKind constants.

Summary: Tasks represents user units or work, associated with consumed and produced resources.
Consumed resource represent both execution and data resources and are exposed
through the operation list_consumed. The combining of execution and data resources is
inconsistent with the explicit declaration of the process argument (the execution resource)
supplied during task creation. Secondly, the process argument type is inconsistent with
the state semantics expected from a process (namely the exposure of state in a form
equivalent to a task state).

resolved and closed

Summary: The create_workspace operation takes a sequence of Users as an argument qualifying an
access control list. However, no operations are available on Workspace to retrieve or
modify the rights granted under the ACL. The list_workspaces operation is provided as a
mechanism through which all workspaces to which a User is associated can be retrieved.
In the case of the list_workspaces operation there is not mechanisms through which users
other than the creating user can be notified of the association to a workspace.

resolved and closed

Summary: Specification states “These operations will add and remove Containments of resources in a
Workspace.” This statement is misleading in that Containment types are not referenced.

resolved and closed

Summary: Structural Feature list is inconsistent with IDL. The feature sent_to is not declared in the IDL
of the Message object. This is ok if we assume that message is a locality constrained
relative to the domain of the User object that the message belongs to. However, if Message
is locally constrained, we need a user centric factory through which messages can be
created.

resolved and closed

Summary: The workspace operation – list_resource_by_type contains the resourcetype argument that
is a string, however semantics of the string are undefined.
Recommend that the type argument be considered as a filter against which object
references are tested. The resourcetype operation argument should be changed to a
CORBA::TypeCode.

resolved and closed

Summary: CDL delcaration of state_set are redundant with respect to the IDL definition.
Remove CDL and integrate enumeration table with Connection State description.

Remove CDL and integrate enumeration table with Connection State description.

Summary: Features listed under the “Structural Features List are inconsistent with the specification and
redundant with respect to the subsequent documented features within the User sub-section.

resolved and closed

Summary: The semantics of max_mumber argument used in several list operations is undefined.

resolved and closed

Summary: Operation are provided for changing state from connected to disconnected. This is
duplicated by the nature of the connectstate attribute declaration.

Change connectstate to a readonly attribute.

Summary: BaseBusienssObject is defined as an identifiable, transactional and life-cycle aware
object. Two issues are identified with the currently IDL definition.
· the inherited TransactionalObject is currently a depreciated interface
· the interface uses CosObjectIdentity::IdentifiableObject as the means through which
objects are comparable (e.g. used to identify an object such as a resource during an
operation to remove the identifies instance from a Workspace). IdentifiableObject
provides identity within a single administrative domain, however, Workspaces may
contain references from local and remote domains. As such, the identity as returned
from IdentifiableObject may be the same for two distinctly different references
contained within a single workspace, creating an ambiguity for operations such as
object removal.

issue resolved, see below

Summary: The current specification of AbstractPerson is declared as a placeholder for the definition of
a generally agreed definition of person. Current initiatives within the OMG are addressing
this in the light of definitions of person within the healthcare, manufacturing and finance
domains. As an interim measure some level of interoperability is required to support the
declaration of attributed data to the AbstractPerson as it is currently not possible to
attribute the name of a person (or other information) in an interoperable manner.

resolved and closed

Summary: Usage and Containment are declared under the list of core Task and Session interfaces,
however, both Usage and Containment are empty interfaces that are not referenced by
any operations within the specification.

resolved and closed