Issue 3580: Cannot attribute an additional MemberKind to an exiting Member                                                                                                                                          (negotiation-ftf)
Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net)
Nature: Uncategorized Issue
Severity: 
Summary: 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.

Resolution: 
Revised Text: Membership has been redefined as an abstract interface. Association of a membership model
and the membership object has been clarified through the addition of an explicit abstract
Simulator interface.
The add_member operation is renamed to join, remove_member operation renamed to leave,
addition of add_roles and remove_roles for role modification. Specification of join restricted to
association of a user and does not support role modification. Role modification enabled under
the add_roles and remove_roles operations. Additional operations are added supporting access
to the role to user associations and member listing (influenced by 3950 and 3952).
Member join
in Session::User user,
in Labels roles
) raises (
AttemptedCeilingViolation,
AttemptedExclusivityViolation,
RecruitmentConflict,
RoleAssociationConflict,
MembershipRejected,
UnknownRole
);
void leave(
in CommunityFramework::Member member
) raises (
RecruitmentConflict,
UnknownMember
);
void add_roles(
in CommunityFramework::Member member,
in Labels roles
) raises (UnknownMember,
RoleAssociationConflict,
UnknownRole
);
void remove_roles(
in CommunityFramework::Member member,
in Labels roles
) raises (
UnknownRole,
UnknownMember,
CannotRemoveRole
);
Actions taken:
April 24, 2000: received issue
February 27, 2001: closed issue
Discussion: 
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.
End of Annotations:=====
From: "Stephen McConnell" <mcconnell@osm.net>
To: "Juergen Boldt" <juergen@omg.org>
Subject: Community Framework issue - attribution of a MemberKind to an
exiting Member
Date: Mon, 24 Apr 2000 01:12:53 +0200
Message-ID: <000401bfad79$73d218a0$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
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
Importance: Normal
Content-Type: multipart/alternative;
	      boundary="----=_NextPart_000_0005_01BFAD8A.375D59A0"
X-UIDL: n06e9G7Fe9=epd9>TI!!

 
Juergen:
 
Please find below an issue to be raised under the (to be rechartered)
Negotiation FTF.
 
Specification: ECDTF Community Framework 
Issue: Cannot attribute an additional MemberKind to an exiting Member
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.
 
Cheers, Steve.

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