Issues for Party Management Facility RTF 3 discussion list

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

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

Issue 3023: Remove interface get_supported_nodes
Issue 3024: The PMF::RelationshipManager should be renamed
Issue 3025: Remove the person and organization abstractions altogethe
Issue 3026: The Node class issue(s)
Issue 3027: Fix case sensitive #typedef declarations (Type type and Types types).
Issue 3028: Manager interfaces need to explain precisely when DuplicateObject exception
Issue 3029: Clarify when set_contact_information replaces an existing contact point
Issue 3030: Clarify what effective_end attribute returns when there isn't a known value
Issue 3031: CommonContainer declares exceptions but never throws/defines them
Issue 3032: Modify text description to match method names
Issue 3033: Role interface on page 41 declares attribute role_name which is double talk
Issue 3035: Role interface on page 41
Issue 3036: Remove requirement to derive CommonObject from TransactionalObject
Issue 3037: : Module name CosFinance should be modified to conform with FDTF direction
Issue 3038: Role, Node and Relationship interfaces should be in common FDTF module
Issue 3039: Role, Node and Relationship interfaces should be in common FDTF module
Issue 3413: The NodeManager interface doesn't make sense
Issue 3414: ContactInformationFactory issue
Issue 3415: place a create_role_type method on the RoleManager interface.
Issue 3416: Locator interface issue
Issue 3861: module name used for PMF should comply with the OMG IDL Style Guide

Issue 3023: Remove interface get_supported_nodes (partyman-fac-rtf)

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.

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.

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.

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.

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.

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.  

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.

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

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.

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.

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

Change attribute to simply 'name'.

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'.

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.

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

Suggested Action:

Module name to be determined.

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

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

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

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.

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

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.

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.