Party Management Facility Avatar
  1. OMG Specification

Party Management Facility — Open Issues

  • Acronym: PARTY
  • Issues Count: 21
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
PARTY-21 module name used for PMF should comply with the OMG IDL Style Guide PARTY 1.0b1 open
PARTY-20 Locator interface issue PARTY 1.0b1 open
PARTY-19 place a create_role_type method on the RoleManager interface. PARTY 1.0b1 open
PARTY-18 ContactInformationFactory issue PARTY 1.0b1 open
PARTY-17 The NodeManager interface doesn't make sense PARTY 1.0b1 open
PARTY-16 Role, Node and Relationship interfaces should be in common FDTF module PARTY 1.0b1 open
PARTY-15 Role, Node and Relationship interfaces should be in common FDTF module PARTY 1.0b1 open
PARTY-14 : Module name CosFinance should be modified to conform with FDTF direction PARTY 1.0b1 open
PARTY-13 Remove requirement to derive CommonObject from TransactionalObject PARTY 1.0b1 open
PARTY-12 Role interface on page 41 PARTY 1.0b1 open
PARTY-11 Role interface on page 41 declares attribute role_name which is double talk PARTY 1.0b1 open
PARTY-10 Modify text description to match method names PARTY 1.0b1 open
PARTY-9 CommonContainer declares exceptions but never throws/defines them PARTY 1.0b1 open
PARTY-8 Clarify what effective_end attribute returns when there isn't a known value PARTY 1.0b1 open
PARTY-7 Clarify when set_contact_information replaces an existing contact point PARTY 1.0b1 open
PARTY-6 Manager interfaces need to explain precisely when DuplicateObject exception PARTY 1.0b1 open
PARTY-5 Fix case sensitive #typedef declarations (Type type and Types types). PARTY 1.0b1 open
PARTY-4 The Node class issue(s) PARTY 1.0b1 open
PARTY-3 Remove the person and organization abstractions altogethe PARTY 1.0b1 open
PARTY-2 The PMF::RelationshipManager should be renamed PARTY 1.0b1 open
PARTY-1 Remove interface get_supported_nodes PARTY 1.0b1 open

Issues Descriptions

module name used for PMF should comply with the OMG IDL Style Guide

  • Key: PARTY-21
  • Legacy Issue Number: 3861
  • Status: open  
  • Source: Gazebo Software Solutions ( Amy Griffis)
  • Summary:

    The module name used for PMF should comply with the OMG IDL Style
    guide. "Df" should be used as a prefix to be recognized as a domain
    facility.

  • Reported: PARTY 1.0b1 — Mon, 18 Sep 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Locator interface issue

  • Key: PARTY-20
  • Legacy Issue Number: 3416
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    4. The Locator interface is geared toward queries based on an SQL like
    syntax. This is not necessarily receptive to LDAP searches. An
    additional method ­ or a signature modification - should be defined to
    better suite a PMF that has been implemented using a hierarchical
    structure such as LDAP.

  • Reported: PARTY 1.0b1 — Mon, 13 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

place a create_role_type method on the RoleManager interface.

  • Key: PARTY-19
  • Legacy Issue Number: 3415
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    3. There should be a way to programmatically create a new role type.
    Possibly place a create_role_type method on the RoleManager interface.

  • Reported: PARTY 1.0b1 — Mon, 13 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

ContactInformationFactory issue

  • Key: PARTY-18
  • Legacy Issue Number: 3414
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    2. The ContactInformationFactory should accept the values of the
    ContactInformation as parameters to its create method similar to
    PartyManager::Create. It is likely that users will flatten the
    ContactInformation into simple properties on the Party and/or Role.
    This possibility should be acknowledged as a valid approach and should
    be suggested or minimally documented in the specification.

  • Reported: PARTY 1.0b1 — Mon, 13 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

The NodeManager interface doesn't make sense

  • Key: PARTY-17
  • Legacy Issue Number: 3413
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    1. The NodeManager interface doesn't make sense and should be eliminated
    from the specification.

  • Reported: PARTY 1.0b1 — Mon, 13 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Role, Node and Relationship interfaces should be in common FDTF module

  • Key: PARTY-16
  • Legacy Issue Number: 3039
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    Issue: Role, Node and Relationship interfaces should be in common FDTF module (CosFinance)

    Suggested Action:

    Move them and resolve references to them to be scoped within new module

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Role, Node and Relationship interfaces should be in common FDTF module

  • Key: PARTY-15
  • Legacy Issue Number: 3038
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    Issue: Role, Node and Relationship interfaces should be in common FDTF module (CosFinance)

    Suggested Action:

    Move them and resolve references to them to be scoped within new module

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

: Module name CosFinance should be modified to conform with FDTF direction

  • Key: PARTY-14
  • Legacy Issue Number: 3037
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    Issue: Module name CosFinance should be modified to conform with FDTF direction

    Suggested Action:

    Module name to be determined.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Remove requirement to derive CommonObject from TransactionalObject

  • Key: PARTY-13
  • Legacy Issue Number: 3036
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    Issue: Derivation of CommonObject from TransactionalObject is not necessary or Factory (Manager) should have derived from it to be consistent, e.g. create within Transaction.

    Suggested Action:

    Remove requirement to derive CommonObject from TransactionalObject. Picture change too on Figure 1 page 12.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Role interface on page 41

  • Key: PARTY-12
  • Legacy Issue Number: 3035
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    Issue: Role interface on page 41, clarify method get_related_object use of effective_date. What if no date supplied. If current one is desired does user have to pass in 'today'.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Role interface on page 41 declares attribute role_name which is double talk

  • Key: PARTY-11
  • Legacy Issue Number: 3033
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    Role interface on page 41 declares attribute role_name which is double talk

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Modify text description to match method names

  • Key: PARTY-10
  • Legacy Issue Number: 3032
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    Issue: CommonContainer methods remove_contained_object and has_contained_object are singular but the textual description below lists them as plural, adding an 's' to the end of each.

    Suggested Action:

    Modify text description to match method names - singular.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

CommonContainer declares exceptions but never throws/defines them

  • Key: PARTY-9
  • Legacy Issue Number: 3031
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    Issue: CommonContainer declares exceptions IsDuplicate, InvalidAggregate and MaxCardinalityExceeded but never throws them or defines them.

    Suggested Action: This was an oversight that occurred when the object model was modified. The exception declarations should be removed.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Clarify what effective_end attribute returns when there isn't a known value

  • Key: PARTY-8
  • Legacy Issue Number: 3030
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    : Clarify what effective_end attribute (getter method) returns when there isn't a known value.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Clarify when set_contact_information replaces an existing contact point

  • Key: PARTY-7
  • Legacy Issue Number: 3029
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    Issue: Clarify when set_contact_information replaces an existing contact point vs. adds another.

    Suggested Action: Add text to method description that explicitly indicates that the contact information is replaced if the type and effective dates match exactly with a preexisting set of contact information. The new contact information will be added if either the type or the date range of effectivity various from the existing set of contact information.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Manager interfaces need to explain precisely when DuplicateObject exception

  • Key: PARTY-6
  • Legacy Issue Number: 3028
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    Issue: Manager interfaces need to explain precisely when DuplicateObject exception will be thrown.

    Suggested Action: Clarify text to indicate that DuplicateObject exception is thrown when the type and identity of the object being created is found to already exist in the system.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Fix case sensitive #typedef declarations (Type type and Types types).

  • Key: PARTY-5
  • Legacy Issue Number: 3027
  • Status: open  
  • Source: Concept Five Technologies ( Bill Swift)
  • Summary:

    Suggested Action:

    Modify variable name to be different (other than case). Change to Type object_type and Types object_types. Page 23 struct definitions for Template and QualifiedObjectIdentity as well as textual descriptions below.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

The Node class issue(s)

  • Key: PARTY-4
  • Legacy Issue Number: 3026
  • Status: open  
  • Source: Gazebo Software Solutions ( Robert Mickley)
  • Summary:

    The Node class is currently derived from CommonObject. This class is a base
    class for Party and supports interfaces for parties to ask about the roles
    they are involved in. There are two issues with this design. The first
    issue is that these interfaces are not supported by PartyRole or
    PartyRelationship. This has the effect of not allowing PartyRoles to have
    Roles. As an example, an employee is a role a person plays in its
    relationship with a company. A manager is role an employee plays in
    relation to it's department. This would be a role of a role. To support
    this, the PartyRole (and the PartyRelationship as well) should have the Node
    interfaces available as well.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Remove the person and organization abstractions altogethe

  • Key: PARTY-3
  • Legacy Issue Number: 3025
  • Status: open  
  • Source: Gazebo Software Solutions ( Robert Mickley)
  • Summary:

    The Party derived types for Person and Organization add nothing to the
    specification and inadvertently get in the way of implementation specific
    derivations. The interfaces have no attributes or operations and the class
    itself is not used for parameterization or return types from any other
    interface. In fact, these two abstractions are not used in anyway
    throughout the specification. It becomes inconvenient when derived types
    for party are needed and these abstraction names can't be used.

    Suggested Action:
    Remove the person and organization abstractions altogether. The add value
    in a non-normative way by demonstrating where such classes would go, but at
    the moment they add nothing.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

The PMF::RelationshipManager should be renamed

  • Key: PARTY-2
  • Legacy Issue Number: 3024
  • Status: open  
  • Source: Gazebo Software Solutions ( Robert Mickley)
  • Summary:

    The class PMF::PartyRelationshipManager is derived from
    PMF::RelationshipManager. The interface has no methods, is not intended as
    an abstract base, so what is it for? The class seems to have no value.

    Suggested Action:
    The PMF::RelationshipManager should be renamed to
    PMF::PartyRelationshipManager and remove the empty derived type altogether.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT

Remove interface get_supported_nodes

  • Key: PARTY-1
  • Legacy Issue Number: 3023
  • Status: open  
  • Source: Gazebo Software Solutions ( Robert Mickley)
  • Summary:

    The abstract base class of NodeManager gives the interface
    "get_supported_nodes". This interface has no meaning and should be
    removed. Since the node interface is a mix-in class for Party, the
    get_supported_parties covers all the potential type information for
    instances. There is no such thing as a type-of node.

    Suggested Action:
    The class NodeManager should be removed altogether.

  • Reported: PARTY 1.0b1 — Fri, 12 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:50 GMT