Issues for Negotiation Facility FTF mailing list

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

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

Issue 3580: Cannot attribute an additional MemberKind to an exiting Member
Issue 3950: Multiple Consumer association to Community and Collaboration types
Issue 3951: Accessibility of external definitions
Issue 3952: Link definition is broken
Issue 3956: Community and Collaboration models severely broken.
Issue 3957: Improvement needed on Membership textual description.
Issue 3958: Duplicate inheritance in Membership interface
Issue 3959: Improvement needed on Membership textual description.
Issue 3960: Separation of Membership versus Role policy required.
Issue 3980: Separation of Collaboration from Encounter inheritance.

Issue 3580: Cannot attribute an additional MemberKind to an exiting Member (negotiation-ftf)

Problem: Under the Community::Membership interface there are operations to add members to a membership under a specific business role.  There are also operations supporting the removal of a business role of an existing member.  The approach to the addition of a supplementary business roles is through the operation add_kind_of_member, however, this is ambiguous when the exclusivity policy is set to false (as the client may be adding a Member instance as a new member or adding a MemberKind to an existing Member).  Propose elimination of the inconsistency by restricting the semantics of add_kind_of_member to new Member instance creation, and supplementing the Membership interface with an additional operation add_kind for attribution of MemberKind roles to  an existing Member instance.

Additional operations provided to support association and retraction of business roles.
Existing operations renamed to improve clarity. Specification of Membership operations
have been substantially updated – refer section 3 and 4 of CommunityFramework,
EC/2000-11-14.

The revised Task and Session 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.  This behaviour is
	required to support association of multiple consumers under the
	Community and Collaboration interfaces.  Current inherited behaviour
	restricts association of event channels to local implementations
	which inconsistent with the stated semantics.

Resolution:

	Revise the definition of BaseBusienssObject such that an
	identifiable structured push consumer is passed as an argument,
	returning a structured push supplier as opposed to the current
	inheritance based exposure a structured event management.

	The following IDL is recommended as a replacement to the definition of
	BaseBusienssObject:

	interface IdentifiableDomainConsumer :
		Session::IdentifiableDomainObject,
		CosNotifyComm::StructuredPushConsumer
		{
	};

	valuetype Timestamp TimeBase::UtcT ;

	interface BaseBusinessObject :
		Session::IdentifiableDomainObject,
		CosLifeCycle::LifeCycleObject
		{
		CosNotifyComm::StructuredPushSupplier add_consumer(
			in IdentifiableDomainConsumer consumer
		);
		Timestamp creation( );
		Timestamp modification( );
		Timestamp access( );
	};
Revised Text:

        Refer to http://www.osm.net/upload/omg-2000-10-15.pdf, section
        1.2 "BaseBusienssObject Revision".
CommunityFramework specification has been updated to include the required
modification of the Task and Session specification of the definition of BaseBusinessObject to
the following IDL:

 There are several occurrences within the Negotiation and
	  Task and Session specification of exception, enumeration and
        struct declarations that are defined with the scope of object
	  interfaces.  This approach complicates access to these type
	  declarations from the Negotiation Community and Collaboration
	  modules. leading to potential type duplication.

Resolution:

	  Resolution of the problem can be achieved by moving
	  the respective declarations from interface to module level in
	  the Session module and Negotiation modules for Community and
	  Collaboration.

Revised Text:

        Refer to http://www.osm.net/upload/omg-2000-10-15.pdf, section
        1.4 "Declaration in Module versus Interface scope".

The definition of a Link (a relationship declaration) under
        Task and Session formal/00-05-03 is in the form of a struct
        containing an object reference and relationship type identifier.
        These identifiers are declared as constants within the Session
        module. This change to Task and Session between bom/98-07-05
        and the current formal/00-05-03 specification effectively breaks
        the Negotiation model of relationship extension. Restoration of
        module independent extension of Links is possible if the current
        Link declaration is replaced with an extendable valuetype
        definition

Resolution:

        Retract constant LinkKind declarations and replace Link struct
        with a valuetype and set of derived valuetypes. Proposed IDL
        replacement detailed below:

        valuetype BooleanValue boolean;

        valuetype Link
              {
              public AbstractResource resource;
              public BooleanValue primary;
        };

        valuetype Usage : truncatable Link
              {
              public CORBA::StringValue tag;
        };

        valuetype Consumption : truncatable Usage { };
        valuetype Production : truncatable Usage { };
        valuetype Collection : truncatable Link { };
        valuetype Containment : truncatable Collection { };
        valuetype Rights : truncatable Link { };
        valuetype Access : truncatable Rights { };
        valuetype Administration : truncatable Access { };
        valuetype Execution : truncatable Rights { };
        valuetype Ownership : truncatable Rights { };
Revised Text:

        Refer to http://www.osm.net/upload/omg-2000-10-15.pdf, section
        1.3 "Link Revision".Detailed editorial and IDL changes are included under section 9 “Changes to the adopted
Task and Session Specification” of the finalized CommunityFramework specification under
document number EC/2000-11-14.

DocumentFramework, DomFramework and CommunityFramework
	specifications are broken as a result of the changes  
	introduced to the Task and Session specification 
	formal/2000-05-02 (refer detailed issues 1, 2 and 3 - 
	posted 15 OCT 2000) and proposed revisions under 
	EC/2000-10-01. 

	* To a large extend the interfaces defined under the 
	  SessionFramework are now redundant. 

	* Definition of links between resource types concerning 
	  community services must be redefined based on an 
	  extendable Link architecture (raised under issue 1).

	* Issues 3461-3474 reflect a level of complexity of the 
	  original specification in terms of the management of 
	  control types relative to containing resource type. 
	  During assessment of issues, it has been identified 
	  that the specifications can be substantially simplified 
	  and clarified through the use of valuetypes when defining 
	  control structures. This approach will enable elimination 
	  of the module thereby simplifying significantly the overall 
	  scope of the specifications and should be addressed prior 
	  to finalisation.

Resolution:

	A recommended revision incorporating rationalisation of all 
	CommunityFramerwork interfaces, incorporating rationalisation
	of underlying Task and Session specification is proposed under 
	document number EC/2000-10-02 (supporting UML under 
	EC/2000-10-03.

The description of Membership, Member and MembershipKind 
	presented in 99-07-03 is overly complex and should be 
	re-written (simplification and clarification) taking into 
	account underlying revisions to the Task and Session 
	specification formal/2000-05-02.

Resolution:

	A recommended revision to the textual description of Membership 
	and related interfaces is proposed under EC/2000-10-02, Part 2.

Membership is currently defined as a type of 
	AbstractResource. In addition two derived types (Community 
	and Encounter) also inherit from AbstractResource. 
	Elimination of this conflict can be achieved by declaring 
	Membership as an abstract interface.

Resolution:

	A recommended revision to the Membership interface is 
	proposed under EC/2000-10-02, Part 2. The revision involves
	retraction of inheritance of AbstractResource and declaration of 
	the interface as abstract.

The Member type represents an association of a User to a 
	Membership, as such it should be re-defined as a type 
	of Link.  The current specification is currently broken 
	and must be recast against an extendable Link model. 

Resoliution:

	Resolution of this issue is proposed under EC/2000-10-02, 
	Part 2, in conjunction with resolution of issues defined under 
	EC/2000-10-01.

MembershipKind combines both the policy of a Membership and 
	the policy of different business roles within a membership. 
	These notions should be separated into independent control 
	objects.

Resolution:

	Resolution of this issue is proposed under EC/2000-10-02, 
	Part 2, involving the separation of membership and role
	policy into distinct types.

Negotiation FTF, CollaborationFramework module.
	The definition of Encounter combines the notion of a
	Membership and rules relating to member association 
	with rules relating to process execution (e.g. derived 
	Collaboration interface).  In the case of Collaboration 
	the current inheritance model eliminates the possibility 
	for independent declaration of process focuses role 
	models as distinct from the roles attributed to different 
	members of a membership.  While the object model 
	expressing roles from the two different perspectives 
	are equivalent at an interface level, the instance 
	values and lifecycles are independent.  It is recommended 
	that the notion of Encounter be restricted to the 
	management of a set of members, sharing a common view 
	on a collaborative process execution.  Moving the 
	collaboration process semantics out of the Encounter 
	inheritance hierarchy can be achieved by defining a 
	relationship between Encounter and the active process 
	that an Encounter is co-ordinating.  Once the notion of 
	process is separated from the notion of membership, the 
	respective control models can coexist.  Secondly, given 
	formal separation of Membership and process, the existing 
	usage relationships derived from the inherited
	Task interface by Encounter can be used to manage the 
	subject of collaborative interaction - as such, the 
	subject relationship can be removed from Engagement, 
	Voting and Collaboration.

Resolution:

	- introduced explicit definition of a processor as a 
	  base type for collaboration, associated to a Task by
	  a declared relationship
	- introduced explicit definition of a processor as a base
	  type for Collaboration (as per Task Session notion of 
	  Task and processor)
	- retract the association of a subject of a collaboration
	  in favour of the existing usage relationships between 
	  a processor and a Task.