Issue 3734: Definition of Link as a valuetype (section 2.5.3, p 2-6)remains outstanding (ts-rtf)
Source: Fujitsu (Mr. Stephen McConnell, stephen.mcconnell(at)au.fujitsu.com)
Nature: Uncategorized Issue
Severity: 
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.
Resolution: 
Revised Text: 
Actions taken:
June 29, 2000: received issue
Discussion: 

End of Annotations:=====
From: "Stephen McConnell" <mcconnell@osm.net>
To: "Juergen Boldt" <juergen@omg.org>
Subject: RE: ISSUES on Task and Session dtc/99-08-02
Date: Thu, 29 Jun 2000 05:13:25 +0200
Message-ID: <000001bfe177$fd4f8c70$0a01a8c0@osm.net>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
Content-Type: multipart/alternative;
	      boundary="----=_NextPart_000_0001_01BFE188.C0DACD70"
X-UIDL: ~p+!!X,Xd9Y"5e9#U<e9

Juergen:
 
One more issue to add to the Task and Session issues list.  
Can you send back to me the issue number for this one, and the four
other issues posted following the Oslo meeting.
 
Cheers, Steve.
 

 
Specification: Task and Session, formal/00-05-03
Issue: Definition of Link as a valuetype (section 2.5.3, p 2-6)
remains outstanding.
Details: 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.


-----Original Message-----
From: Stephen McConnell [mailto:mcconnell@osm.net]
Sent: Monday, 19 June, 2000 17:20
To: Juergen Boldt
Subject: ISSUES on Task and Session dtc/99-08-02

 
Specification: Task and Session
Document Number: dtc/99-08-02
 

 
Issue: Incorrect event name in Task Structured Event Table.
Details: 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.
 
Issue: Missing LinkKind declaration in Task LinkKind Table.
Details: The LinkKind table for Task on page 32 does not define the
abstract link "uses".
 
Issue: Inconsistency between summary and detailed LinkKind Tables.
Details: 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. 
 
Issue: Insufficency of Processor to Task semantics.
Details: 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).
 

 
Cheers, Steve.

Stephen J. McConnell, OSM sarl
Business Components for Electronic Commerce
http://www.osm.net
mailto:mcconnell@osm.net