The CosGraphs module specifies that Traversals are be created by the
TraversalFactory::create_traversal_on() operation, which returns a Traversal
and takes 3 input parameters: a root Node, a TraversalCriteria, and a mode flag.

In the PDM Enablers PdmViews module, it is specified that PdmContext is a subtype of
TraversalCriteria, and thus a PdmContext can be used to create a Traversal. The
PdmContext is effective as a filter to specify that only the items of interest to the client
are returned. However, it is insufficient to create an effective Traversal object.
Nowhere is there defined a traversal path name, algorithm or strategy which indicates
which roles and relationships to follow.

As a possible solution, it is sugggested that the PdmContext not inherit
TraversalCriteria. Rather a TraversalCriteria should be created by a new interface's
operation, which takes as input both a PdmContext and some definition of a
PDM Enablers-specific traversal path.

resolved and closed. Read spec to view UML diagrams

The Identifiable and IdentificationContext interfaces provide a flexible way for PDM Enablers implementations to support multiple identifiers for items. An IdentificationContext can be found by giving the name of the IdentificationContext. The specification should give better guidance for how these names should be formed and what their values should be. The convention should take into account the type of the item that is identified by the IdentificationContext as well as an identifier for the unique context. For implementations or sites that support only a single IdentificationContext per item type, the name of the single IdentificationContext should be specified by the PDM Enablers specification. It is suggested that a single Identification Context name be equal to the name of the item identified by the IdentificationContext.

resolved/accepted

The PDM Enablers specification does not specify interfaces to log into the PDM system and authenticate the user. The Security service has appropriate interfaces. The PDM Enablers specification should specify details for how the server and client should use the security service interfaces to authenticate the user with the PDM system.

see below

The PDM Enablers does not specify how the client should obtain the initial PDM System interface. The specification should detail how the implementation should register objects with the Naming Service and how clients should use them to find the PdmSystem object.

This issue was referred to RFP, and is addressed in the PDM Enablers v2 revised proposal.

The PDM Enablers define several factories, which are interfaces that create other objects. The PdmSystem object is a FactoryFinder, which supports a find_factories operation. The find_factories operation takes a Name Service style composite name as a parameter to identify the Factory. But the form and values for these names for each of these factories is not defined by the PDM Enablers specification.

The PDM Enablers specification should be enhanced to specify names for these factories. It is suggested that the PdmSystem object supports one factory of each type, and that the Name of the factory be equal to the module name plus the interface name of the factory.

accepted in principle

Several commercial PDM systems include workflow capabilities. The PDM Enablers specification discusses generally, but does not specify in detail how the interfaces of the Workflow Management Facility interact with the PDM Enablers interfaces. This should be discussed in more detail.

see above

Description:
Factories to non-abstract subtypes of Effectivity
(DatedEffectivityFactory,LotEffectivityFactory,
SerialNumberedEffectivityFactory)
The interface Effectivity holds an attribute "name" which can not be
populated by the factories create
method.

See the resolution to issue 3309

Description:
All Factories for non-abstract subtypes of Qualification
(LifeCycleQualificationFactory, LocationQualificationFactory,
DisciplineQualificationFactory,
DatedEffectivityFactory,LotEffectivityFactory,
SerialNumberedEffectivityFactory)
Qualification is Manageable. The population of the attributes of these
supertype should
be allowed during creation via a generic PropertySet attribute to the
create method of the factories.

accepted and resolved

Description:
ViewQualification is an abstract interface. Why is a
"ViewQualificationFactory"
defined?

accepted in principle