Negotiation Facility Avatar
  1. OMG Specification

Negotiation Facility — All Issues

  • Acronym: NEG
  • Issues Count: 10
  • Description: All Issues
Closed All
All Issues

Issues Descriptions

Community and Collaboration models severely broken.

  • Key: NEG-53
  • Legacy Issue Number: 3956
  • Status: closed  
  • Summary:

    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.
  • Reported: NEG 1.0b1 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — NEG 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Link definition is broken

  • Key: NEG-52
  • Legacy Issue Number: 3952
  • Status: closed  
  • Summary:

    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

  • Reported: NEG 1.0b1 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — NEG 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Separation of Collaboration from Encounter inheritance.

  • Key: NEG-58
  • Legacy Issue Number: 3980
  • Status: closed  
  • Summary:

    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.
  • Reported: NEG 1.0b1 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — NEG 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Separation of Membership versus Role policy required.

  • Key: NEG-57
  • Legacy Issue Number: 3960
  • Status: closed  
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — NEG 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improvement needed on Membership textual description.

  • Key: NEG-56
  • Legacy Issue Number: 3959
  • Status: closed  
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — NEG 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Duplicate inheritance in Membership interface

  • Key: NEG-55
  • Legacy Issue Number: 3958
  • Status: closed  
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — NEG 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improvement needed on Membership textual description.

  • Key: NEG-54
  • Legacy Issue Number: 3957
  • Status: closed  
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — NEG 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Accessibility of external definitions

  • Key: NEG-51
  • Legacy Issue Number: 3951
  • Status: closed  
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — NEG 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple Consumer association to Community and Collaboration types

  • Key: NEG-50
  • Legacy Issue Number: 3950
  • Status: closed  
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — NEG 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Cannot attribute an additional MemberKind to an exiting Member

  • Key: NEG-49
  • Legacy Issue Number: 3580
  • Status: closed  
  • 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.

  • Reported: NEG 1.0b1 — Mon, 24 Apr 2000 04:00 GMT
  • Disposition: Resolved — NEG 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT