${taskforce.name} Avatar
  1. OMG Task Force

PDM RTF 1.3 — All Issues

Open Closed All
All Issues

Issues Descriptions

PdmContext is insufficient as a TraversalCriteria

  • Key: PDME13-6
  • Legacy Issue Number: 3154
  • Status: closed  
  • Source: Hewlett-Packard ( Duane Silkworth)
  • Summary:

    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.

  • Reported: PDME 1.2 — Tue, 21 Dec 1999 05:00 GMT
  • Disposition: Resolved — PDME 1.3
  • Disposition Summary:

    resolved and closed. Read spec to view UML diagrams

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

IdentificationContext Conventions

  • Key: PDME13-5
  • Legacy Issue Number: 3089
  • Status: closed  
  • Source: Hewlett-Packard ( Duane Silkworth)
  • Summary:

    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.

  • Reported: PDME 1.2 — Mon, 29 Nov 1999 05:00 GMT
  • Disposition: Resolved — PDME 1.3
  • Disposition Summary:

    resolved/accepted

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

Authentication

  • Key: PDME13-2
  • Legacy Issue Number: 3085
  • Status: closed  
  • Source: Hewlett-Packard ( Duane Silkworth)
  • Summary:

    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.

  • Reported: PDME 1.2 — Mon, 29 Nov 1999 05:00 GMT
  • Disposition: Resolved — PDME 1.3
  • Disposition Summary:

    see below

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

Session Management

  • Key: PDME13-1
  • Legacy Issue Number: 3084
  • Status: closed  
  • Source: Hewlett-Packard ( Duane Silkworth)
  • Summary:

    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.

  • Reported: PDME 1.2 — Mon, 29 Nov 1999 05:00 GMT
  • Disposition: Resolved — PDME 1.3
  • Disposition Summary:

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

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

Factory Finder Conventions

  • Key: PDME13-4
  • Legacy Issue Number: 3088
  • Status: closed  
  • Source: Hewlett-Packard ( Duane Silkworth)
  • Summary:

    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.

  • Reported: PDME 1.2 — Mon, 29 Nov 1999 05:00 GMT
  • Disposition: Resolved — PDME 1.3
  • Disposition Summary:

    accepted in principle

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

Workflow

  • Key: PDME13-3
  • Legacy Issue Number: 3087
  • Status: closed  
  • Source: Hewlett-Packard ( Duane Silkworth)
  • Summary:

    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.

  • Reported: PDME 1.2 — Mon, 29 Nov 1999 05:00 GMT
  • Disposition: Resolved — PDME 1.3
  • Disposition Summary:

    see above

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

Factories to non-abstract subtypes of Effectivity

  • Key: PDME13-8
  • Legacy Issue Number: 3310
  • Status: closed  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

    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.

  • Reported: PDME 1.2 — Thu, 10 Feb 2000 05:00 GMT
  • Disposition: Resolved — PDME 1.3
  • Disposition Summary:

    See the resolution to issue 3309

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

Factories for non-abstract subtypes of Qualification

  • Key: PDME13-7
  • Legacy Issue Number: 3309
  • Status: closed  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

    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.

  • Reported: PDME 1.2 — Thu, 10 Feb 2000 05:00 GMT
  • Disposition: Resolved — PDME 1.3
  • Disposition Summary:

    accepted and resolved

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

ViewQualification is abstract

  • Key: PDME13-9
  • Legacy Issue Number: 3312
  • Status: closed  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

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

  • Reported: PDME 1.2 — Thu, 10 Feb 2000 05:00 GMT
  • Disposition: Resolved — PDME 1.3
  • Disposition Summary:

    accepted in principle

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