Issues for Task and Session RTF discussion list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 2680: BaseBusinessObject definition
Issue 2681: Usage and Containment type redundancy
Issue 2682: AbstractPerson
Issue 2683: User – Structural Features List
Issue 2684: CDL state_set reference in connectstate
Issue 2685: connectstate attribute
Issue 2686: max_number argument
Issue 2687: create_workspace operation
Issue 2688: Task process argument
Issue 2689: Message
Issue 2690: Workspace – containment statements
Issue 2691: list_resource_by_type
Issue 2692: Resource event declaration.
Issue 2693: Task structural feature list
Issue 2694:
Issue 2695: Task consumer/producer terminology
Issue 2696: Produces association retraction.
Issue 2697: Task history event filter
Issue 2698: AbstractResource key
Issue 2699: Structural Feature is_in
Issue 2700: Structural Feature bound_to
Issue 2701: list_producers and related operations
Issue 2702: NotRemoved exception
Issue 3168: Management of event consumer association
Issue 3169: Access to resource creation and modification dates
Issue 3170: AbstractResource association count
Issue 3171: Ambiguity of the containment relationship
Issue 3709: Incorrect event name in Task Structured Event Table.
Issue 3710: Missing LinkKind declaration in Task LinkKind Table.
Issue 3711: Inconsistency between summary and detailed LinkKind Tables.
Issue 3712: Insufficency of Processor to Task semantics.
Issue 3734: Definition of Link as a valuetype (section 2.5.3, p 2-6)remains outstanding

Issue 2680: BaseBusinessObject definition (ts-rtf)

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.

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.

The RTF recommends the deprecation of the Usage and Containment interfaces and the
inclusion of new IDL detailing Link and an associated LinkKind supporting associations between
resources. Please refer to the recommendations under section 2.2 of this document.

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.

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.

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

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

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

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.

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

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.

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.

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.

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

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

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

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.

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

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

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.

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.

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.

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.

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

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

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

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

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.

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

 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.