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.

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 LinkKind table for Task on page 32 does not define the abstract link "uses".