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".