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.

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.

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

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

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.

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

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: 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: Module name CosFinance should be modified to conform with FDTF direction

Suggested Action:

Module name to be determined.

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.

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

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

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

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.

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.

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.

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