Product Data Management Enablers Avatar
  1. OMG Specification

Product Data Management Enablers — Open Issues

  • Acronym: PDME
  • Issues Count: 104
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
PDME-100 Behavior of Lockable operations is not defined PDME 1.0b2 open
PDME-102 Exception declaration inconsistent PDME 1.0b2 open
PDME-101 Define the Substitute Usage model PDME 1.0b2 open
PDME-104 PDM RTF issue: no generic "set session properties" operation PDME 1.0b2 open
PDME-103 description of the get_info() operation states PDME 1.0b2 open
PDME-75 2.6.3.2 Relationship Propogation when using the factory methods. PDME 1.0b1 open
PDME-74 Property-sets for non-Attributable relationships PDME 1.0b1 open
PDME-73 UML - IDL consistency of role names PDME 1.0b1 open
PDME-72 The Part - Document relationship PDME 1.0b1 open
PDME-82 Misplaced Usage inheritance from SecurityClassifiable PDME 1.0b1 open
PDME-81 Missing UML inheritances for Usage PDME 1.0b1 open
PDME-79 The names of the relationships are unintuitive, such as prc PDME 1.0b1 open
PDME-78 2.7.1 Concerned that the product structure is at too low a level in the hi PDME 1.0b1 open
PDME-77 Part Description text indicates discrete mfg PDME 1.0b1 open
PDME-76 2.3.3.9 How is this related to ItemRevision::create_next_revision? PDME 1.0b1 open
PDME-86 Clarify and expand the text that explains how or why ECIs yield ECRs. PDME 1.0b1 open
PDME-85 2.9.3.5 EngChangeOrder : Add an “effectivity” (or “do it by”) attribute to PDME 1.0b1 open
PDME-84 Lack of role defintion. PDME 1.0b1 open
PDME-83 2.7.3.2 description of reference_designator attribute PDME 1.0b1 open
PDME-71 The create method on the ItemSolutionFactory interface PDME 1.0b1 open
PDME-70 PDM Enablers section 2.10.3.12 PDME 1.0b1 open
PDME-80 Missing Usage roles PDME 1.0b1 open
PDME-31 Develop Product Definition PDME 1.0b1 open
PDME-30 ISSUE #9 REF: 1.11.3 Workflow , 1.14.4 Workflow Management Coalition (WfMC PDME 1.0b1 open
PDME-39 REF: 1.15 Other Information PDME 1.0b1 open
PDME-38 ISSUE #18 REF: 1.14.2.1.6 Assembly Model PDME 1.0b1 open
PDME-36 REF 1.13.4 ERP: add following bullets PDME 1.0b1 open
PDME-35 REF: 1.13.3 CAD PDME 1.0b1 open
PDME-29 How does SWAP apply? PDME 1.0b1 open
PDME-28 Test, maintenance, and diagnostic information PDME 1.0b1 open
PDME-33 REF: 1.12.6 Develop Process Design and Procurement Agreements PDME 1.0b1 open
PDME-32 Develop Product Design PDME 1.0b1 open
PDME-27 Configuration Management PDME 1.0b1 open
PDME-26 Product Structure definition PDME 1.0b1 open
PDME-25 Document management PDME 1.0b1 open
PDME-24 Manufacturing Implementation PDME 1.0b1 open
PDME-34 REF: 1.12.6 Develop Process Design and Procurement Agreements PDME 1.0b1 open
PDME-37 Differences in Purpose PDME 1.0b1 open
PDME-69 Process - Part relationship PDME 1.0b1 open
PDME-68 $issue.summary PDME 1.0b1 open
PDME-67 $issue.summary PDME 1.0b1 open
PDME-66 $issue.summary PDME 1.0b1 open
PDME-60 $issue.summary PDME 1.0b1 open
PDME-59 $issue.summary PDME 1.0b1 open
PDME-64 $issue.summary PDME 1.0b1 open
PDME-63 $issue.summary PDME 1.0b1 open
PDME-62 $issue.summary PDME 1.0b1 open
PDME-61 $issue.summary PDME 1.0b1 open
PDME-58 $issue.summary PDME 1.0b1 open
PDME-57 $issue.summary PDME 1.0b1 open
PDME-56 $issue.summary PDME 1.0b1 open
PDME-55 $issue.summary PDME 1.0b1 open
PDME-65 $issue.summary PDME 1.0b1 open
PDME-54 $issue.summary PDME 1.0b1 open
PDME-41 Problem creating certain objects PDME 1.0b1 open
PDME-40 Vault attributes shown as being read - write PDME 1.0b1 open
PDME-43 2.10.2 Level of control for Part manufacturing information PDME 1.0b1 open
PDME-42 1.14.1 Relationship to RM-ODP? PDME 1.0b1 open
PDME-53 $issue.summary PDME 1.0b1 open
PDME-52 $issue.summary PDME 1.0b1 open
PDME-49 $issue.summary PDME 1.0b1 open
PDME-48 $issue.summary PDME 1.0b1 open
PDME-45 $issue.summary PDME 1.0b1 open
PDME-44 $issue.summary PDME 1.0b1 open
PDME-51 $issue.summary PDME 1.0b1 open
PDME-50 $issue.summary PDME 1.0b1 open
PDME-47 $issue.summary PDME 1.0b1 open
PDME-46 $issue.summary PDME 1.0b1 open
PDME-18 PDM Enablers IDL uses different include file names than CORBA Services IDL PDME 1.0b1 open
PDME-17 Configuration module: ProductRootToComponent - Relationship PDME 1.0b1 open
PDME-11 IDL consistency Issue for PDM PDME 1.0b1 open
PDME-10 $issue.summary PDME 1.0b1 open
PDME-13 Illegal usage of keyword "context" PDME 1.0b1 open
PDME-12 PDM Enablers issue - PartDataFactory attributes PDME 1.0b1 open
PDME-15 Add relationship from document master directly to vault PDME 1.0b1 open
PDME-14 Change cardinality of ComponentHierarchy-Relationship PDME 1.0b1 open
PDME-16 Add relationships from most main objects to documents PDME 1.0b1 open
PDME-23 Engineering Change Order PDME 1.0b1 open
PDME-22 Editorial changes to mfg/98-02-02 PDME 1.0b1 open
PDME-21 Issue: Alignment of OMG Person/Party models PDME 1.0b1 open
PDME-19 Duplicate Exceptions PDME 1.0b1 open
PDME-20 No City in PdmResponsibility PDME 1.0b1 open
PDME-99 IdentificationContext Considered Harmful PDME 1.0b2 open
PDME-98 PDM RTF issue: "successor" PDME 1.0b2 open
PDME-97 "interface name" is ambiguous PDME 1.0b2 open
PDME-94 Vault object references PDME 1.0b2 open
PDME-93 Convention for Creating Items PDME 1.0b2 open
PDME-92 Attributes PDME 1.0b2 open
PDME-91 Change name DocumentRevisionRelationship to PartDocumentRelationship PDME 1.0b1 open
PDME-96 allow "document type" to be the IdContext "kind" PDME 1.0b2 open
PDME-95 ConfigurationItem PDME 1.0b2 open
PDME-90 Figure needs updates PDME 1.0b1 open
PDME-89 Figure 1 in section "2.2.3.5.1" has two incorrect object names PDME 1.0b1 open
PDME-88 Part Description text indicates discrete mfg, PDME 1.0b1 open
PDME-87 PdmDocumentManagement IDL is obsolete PDME 1.0b1 open
PDME-1 PDM Enablers shall support use of a Note Object PDME 1.0b1 open
PDME-6 Note Objects currently not addressed PDME 1.0b1 open
PDME-5 How can we extend ICOM PDME 1.0b1 open
PDME-9 What Security Systems are used with the PDM Enablers? PDME 1.0b1 open
PDME-8 Use of PDM Enablers. PDME 1.0b1 open
PDME-2 IdentificationContext appears not to be value added PDME 1.0b1 open
PDME-3 Identify cases where interoperability between PDM systems is of use PDME 1.0b1 open
PDME-4 Use of PDM Enablers without modifying them PDME 1.0b1 open
PDME-7 Document and/or Drawing Sheet Information PDME 1.0b1 open

Issues Descriptions

Behavior of Lockable operations is not defined

  • Key: PDME-100
  • Legacy Issue Number: 4222
  • Status: open  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Source: PDME-RTF, derived from issue 2485

    Summary:
    In section 3.3.8, the following Note appears: "Note ­ It is up to the inheriting classes to include the locking or checks for
    locks on dependent objects. For example, it is up to the Document classes to define what happens to DocumentRevisions when the
    Document object is locked."
    But in fact, nothing in DocumentManagement defines this, nor does anything in ProductStructure define the effects of locking on
    PartRevisions, nor does anything in ManufacturingImplementation define the effects of locking on ProcessRevisions, etc. The PDM
    Enablers should define the common interoperable locking behaviors on each class that inherits from Lockable, and where necessary
    at least say that locking behavior is implementation-defined.

  • Reported: PDME 1.0b2 — Wed, 14 Mar 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception declaration inconsistent

  • Key: PDME-102
  • Legacy Issue Number: 4259
  • Status: open  
  • Source: Eigner + Partner AG ( Andreas Fester)
  • Summary:

    The exception declarations for the operations get_viewable_info and get_updatable_info of interface PdmFramework::Attributable are inconsistent. get_updatable_info can raise the PDM_EXCEPTIONS and PdmFoundation::InvalidProperties, while get_viewable_info can not raise any exceptions at all. Since both operations only provide one out parameter, the exception PdmFoundation::InvalidProperties does not make sense for either of them. Suggestion is to let both of them raise only the PDM_EXCEPTIONS.

  • Reported: PDME 1.0b2 — Fri, 6 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Define the Substitute Usage model

  • Key: PDME-101
  • Legacy Issue Number: 4223
  • Status: open  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Source: JPDM team (jpdm.team@mscsoftware.com)

    Summary:
    In 8.3.19, the intent of the Substitute relationship is clearly defined, but the rules for its usage are not. In particular,
    section 8.3.19 should specify that a Usage that plays the "base" role in a Substitute relationship cannot play the "substitute"
    role in a different Substitute relationship, or provide some other mechanism for disambiguating "base" Usages. In creating a
    unique Bill of Materials, it is necessary to have a conceptual "primary" or "base" Usage that is distinct from all "substitute"
    Usages. It is possible that there are multiple "base" Usages for different mutually exclusive Effectivity contexts; and it is
    possible that the base Usage for one Effectivity context is an admissible substitute Usage in another Effectivity context. In
    order to guarantee consistent interpretation of assembly models, the specification must address these aspects of the object
    model.

  • Reported: PDME 1.0b2 — Wed, 14 Mar 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

PDM RTF issue: no generic "set session properties" operation

  • Key: PDME-104
  • Legacy Issue Number: 4565
  • Status: open  
  • Source: NIST ( David Flater)
  • Summary:

    This new JCAD issue looks to apply equally well to PDM Enablers.
    We might want to add an operation like

    PdmSystem::set_session_properties (
    in CosPropertyService::Properties session_properties
    ) raises (PDM_EXCEPTIONS,
    PdmFoundation::InvalidProperties,
    PdmFoundation::CannotChangeWithoutReconnect);

    A matching get_properties operation may not be needed if everyone
    thinks that this would be redundant with PdmServer::get_properties.

  • Reported: PDME 1.0b2 — Thu, 6 Sep 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

description of the get_info() operation states

  • Key: PDME-103
  • Legacy Issue Number: 4260
  • Status: open  
  • Source: Eigner + Partner AG ( Andreas Fester)
  • Summary:

    The description of the get_info() operation states: "... In either case, even if an exception is raised, all recognized and permitted attributes are returned." However, an operation can not return any values when an exception is raised (see section 3.12.2 of "The Common Object Request Broker: Architecture and Specification", Rev. 2.3.1). Therefore, the sentence mentioned should be removed from the PDM Enablers specification.

  • Reported: PDME 1.0b2 — Mon, 9 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.6.3.2 Relationship Propogation when using the factory methods.

  • Key: PDME-75
  • Legacy Issue Number: 2232
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2.6.3.2 How does architecture address relationship propagation by the factory methods? “copy forward”

  • Reported: PDME 1.0b1 — Tue, 1 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property-sets for non-Attributable relationships

  • Key: PDME-74
  • Legacy Issue Number: 2168
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: The DocumentRevision (2.7.3.4), DesignSupplier (2.7.3.3) and
    PartSupplier (2.7.3.17) relationships inherit from PdmReferencesRelationship.
    These relationships have no specified attributes, and
    PdmReferencesRelationship is not Attributable. But the factories for
    these relationships take a PropertySet parameter. How does the client
    subsequently reach any property values so attached?
    A similar problem exists with the PartData, PartDataIteration,
    PartStructure, PartStructureIteration and PartMasterComposition
    relationships (which inherit from PdmContainmentRelationship), but a
    previous issue recommends deletion of the factories for Containment
    relationships.
    A related problem exists for Alternate and Substitute and Usage
    relationships, which also inherit from PdmReferencesRelationship
    and are not Attributable. In their case, only the properties
    defined as "attributes" in the specification are accessible.

  • Reported: PDME 1.0b1 — Wed, 4 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML - IDL consistency of role names

  • Key: PDME-73
  • Legacy Issue Number: 2166
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: The role names in the IDL and would-be CDL are NOT the same
    as the role names in the UML in section 2.7, e.g. UML prcl_of_dr
    is interface PrclOfDr.

    (In most sections, the role names do not appear in the UML at all.
    The only other section in which the role names appear in the UML
    model is 2.2, and in that section the UML and IDL match.)

    Recommendation: Either remove the role names from the model in 2.7.2
    or spell them to match the IDL.

  • Reported: PDME 1.0b1 — Wed, 4 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Part - Document relationship

  • Key: PDME-72
  • Legacy Issue Number: 2164
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: The DocumentRevisionRelationship appears to be a general-purpose
    mechanism for relating Documents to Parts, in that it is many-to-many.
    And yet it specifically relates Part Revisions (PRCL) to Document
    Revisions rather than Document Masters. It seems that two ideas have
    been mixed here:
    a) the relationship that binds a definitive Document to the Part,
    such that each Revision of the document describes a Revision of the
    part, e.g. the part geometry model; and
    b) a general-purpose relationship that attaches arbitrary
    Documents to one or more Parts, such as analysis reports, Issue
    documents, design recommendations, etc.

  • Reported: PDME 1.0b1 — Wed, 4 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misplaced Usage inheritance from SecurityClassifiable

  • Key: PDME-82
  • Legacy Issue Number: 2243
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Reference: PDM Enablers 2.7.3.2, 2.7.3.20

    Problem: As modelled, AssemblyComponentUsage inherits from
    SecurityClassifiable, but Usage does not. If Usage is ever to have other
    subtypes (which is the only reason for separating AssemblyComponentUsage),
    the other usage relationships (such as MakeFrom) might also be classified.
    Usage should inherit from SecurityClassifiable, and AssemblyComponentUsage
    should inherit that from Usage. When fixing this in the UML, "Classifiable"
    should be properly spelled "SecurityClassifiable".

  • Reported: PDME 1.0b1 — Mon, 7 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing UML inheritances for Usage

  • Key: PDME-81
  • Legacy Issue Number: 2242
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Reference: PDM Enablers 2.7.2

    Problem: Usage inherits from PdmReferenceRelationship and Node, but these
    inheritances do not appear in the UML diagram in 2.7.2. They should.

  • Reported: PDME 1.0b1 — Mon, 7 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The names of the relationships are unintuitive, such as prc

  • Key: PDME-79
  • Legacy Issue Number: 2239
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The names of the relationships are unintuitive, such as prcl… The rest of the document does not use abbreviations such as these, why start here?

  • Reported: PDME 1.0b1 — Thu, 3 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.7.1 Concerned that the product structure is at too low a level in the hi

  • Key: PDME-78
  • Legacy Issue Number: 2238
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2.7.1 Concerned that the product structure is at too low a level in the hierarchy. This could be because the module name does not reflect the model, which is part structures. The abstract product functional capabilities are described in configuration management (2..11)

  • Reported: PDME 1.0b1 — Thu, 3 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Part Description text indicates discrete mfg

  • Key: PDME-77
  • Legacy Issue Number: 2237
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Part Description text indicates discrete mfg, how could this be expanded for larger industry in the future.
    2.7.1 Part description is targeted towards descrete manufacturing, can it be expanded to other industry areas

  • Reported: PDME 1.0b1 — Thu, 3 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.3.3.9 How is this related to ItemRevision::create_next_revision?

  • Key: PDME-76
  • Legacy Issue Number: 2236
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2.3.3.9 How is this related to ItemRevision::create_next_revision?

  • Reported: PDME 1.0b1 — Thu, 3 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify and expand the text that explains how or why ECIs yield ECRs.

  • Key: PDME-86
  • Legacy Issue Number: 2248
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Clarify and expand the text that explains how or why ECIs yield ECRs.

  • Reported: PDME 1.0b1 — Mon, 7 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.9.3.5 EngChangeOrder : Add an “effectivity” (or “do it by”) attribute to

  • Key: PDME-85
  • Legacy Issue Number: 2247
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Add a "do it by" (or "effectivity") attribute to EngChangeOrder (2.9.3.5), which designates a target date for Engineering to complete the changes.

  • Reported: PDME 1.0b1 — Mon, 7 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lack of role defintion.

  • Key: PDME-84
  • Legacy Issue Number: 2245
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 2.9.3.1 All roles are defined, therefore, non-issue for this part.

  • Reported: PDME 1.0b1 — Mon, 7 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.7.3.2 description of reference_designator attribute

  • Key: PDME-83
  • Legacy Issue Number: 2244
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Again in 2.7.3.2 description of reference_designator attribute talks about the as_required attribute. Is this the approximate attribute from PdmFramework::Measurement or a new attribute not specified?

  • Reported: PDME 1.0b1 — Mon, 7 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The create method on the ItemSolutionFactory interface

  • Key: PDME-71
  • Legacy Issue Number: 2158
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The create method on the ItemSolutionFactory interface should raise
    ITEM_CREATE_EXCEPTION

  • Reported: PDME 1.0b1 — Mon, 2 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

PDM Enablers section 2.10.3.12

  • Key: PDME-70
  • Legacy Issue Number: 2154
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: The data type of attribute ProcessStep::duration is "string", but
    duration is a quantity of time, and should be represented as a Measurement
    type.

  • Reported: PDME 1.0b1 — Fri, 30 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing Usage roles

  • Key: PDME-80
  • Legacy Issue Number: 2241
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Reference: PDM Enablers 2.7.3.20

    Problem: The Assembly and Component Role interfaces are defined in 2.7.4,
    but not in any IDL snippet in 2.7.3. They should be defined in 2.7.3.20
    (Usage), which is the parent relationship.

  • Reported: PDME 1.0b1 — Mon, 7 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Develop Product Definition

  • Key: PDME-31
  • Legacy Issue Number: 1910
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #10 REF: 1.12.3 Develop Product Definition
    Manage Libraries of Existing Modules (Parts)

    3. Define new part types.
    By a Parts Classification system.

    Should include integration to third party classification tools (i.e. Aspect).

    [ASPECT is a classification tool used by the electronics industry. Its functionality includes searches on product metadata.]

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ISSUE #9 REF: 1.11.3 Workflow , 1.14.4 Workflow Management Coalition (WfMC

  • Key: PDME-30
  • Legacy Issue Number: 1909
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #9 REF: 1.11.3 Workflow , 1.14.4 Workflow Management Coalition (WfMC)

    Does the design support a change process whereby workflow management is jointly owned by PDM and WORKFLOW? Consider this scenario: a REA is submitted for a change in the product design. The request is accepted and elevated to an ECR. So far, we"re under the purview of PDM. However, the work behind changing the associated 3-D CAD model would be adminstered by WORKFLOW. When finished, the new model is distributed for review and approval. Each system must coordinate their respective work activity with one another.

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

REF: 1.15 Other Information

  • Key: PDME-39
  • Legacy Issue Number: 1920
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #20 REF: 1.15 Other Information

    Other materials are not provided as part of this proposal.

    How about embedded software (test software and process control software associated with the part)? Is there any software process management tool interface strategy (i.e. Clear Case, PCMS, etc.)?

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ISSUE #18 REF: 1.14.2.1.6 Assembly Model

  • Key: PDME-38
  • Legacy Issue Number: 1918
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: AP203 requires a specific revision of an assembly specification to refer to specific revisions of the component parts. This structure model is intractable in a concurrent engineering work-in-progress environment, because all the parts of an assembly are undergoing simultaneous rapid versioning in each aspect of their descriptions.

    This is a very important point and this discussion needs to be tied to the product"s status within an organization"s life cycle model.

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

REF 1.13.4 ERP: add following bullets

  • Key: PDME-36
  • Legacy Issue Number: 1915
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #15 REF: 1.13.4 ERP

    Add the following bullets:

    · Provide item master ownership strategy by attribute between PDM and ERP systems.
    · Provide item master ownership strategy based on product life cycle between PDM and ERP systems.
    · PDM and ERP systems need to be able to view each other"s BOM views.
    · System of record strategy need so meet individual organization"s needs.

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

REF: 1.13.3 CAD

  • Key: PDME-35
  • Legacy Issue Number: 1914
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #14 REF: 1.13.3 CAD

    Add the following bullet:

    · Able to convert native CAD file into neutral image (e.g., PDF, PostScript) when a view is requested. Can handle complex file stuctures (i.e. 3d CAD).

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

How does SWAP apply?

  • Key: PDME-29
  • Legacy Issue Number: 1908
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #8 REF: 1.11.3 Workflow , 1.14.4 Workflow Management Coalition (WfMC)

    How does SWAP apply ?

    [SWAP stands for Simple Workflow Access Protocol. As I understand it, it is a protocol for exchanging workflow information. This may be more pertinent for the BODTF.]

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Test, maintenance, and diagnostic information

  • Key: PDME-28
  • Legacy Issue Number: 1907
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #7 REF: 1.9.8 Test, Maintenance, and Diagnostic Information

    Is this within the scope of PDM or in the MES domain?

    [Equipment maintenance is definitely MES. Product diagnostics may employ FMEA, which seems to fall under P/PE scope.]

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

REF: 1.12.6 Develop Process Design and Procurement Agreements

  • Key: PDME-33
  • Legacy Issue Number: 1912
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #12 REF: 1.12.6 Develop Process Design and Procurement Agreements
    Develop Manufacturing Facility Plan
    Is this within the scope of PDM ????

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Develop Product Design

  • Key: PDME-32
  • Legacy Issue Number: 1911
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #11 REF: 1.12.5 Develop Product Design
    Develop Part Design
    3. Provide feedback to other designers when changes to their parts would improve the overall design.
    EngIssueItem to create an issue object.
    EngChangeAffect to associate it to the questionable specifications.

    ERP integration at this stage is crucial!

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Configuration Management

  • Key: PDME-27
  • Legacy Issue Number: 1906
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #6 REF: 1.9.7 Configuration Management

    How are revision rules addressed?

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Product Structure definition

  • Key: PDME-26
  • Legacy Issue Number: 1905
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #5 REF: 1.9.5 Product Structure Definition

    BOI or BOM perspective?

    [Motorola places emphasis on a Bill of Information; that is, product information that goes beyond the traditional notion of BOM. A BOI encapsulates BOM as well as process specifications, test programs, recipes and other manufacturing engineering objects.]

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Document management

  • Key: PDME-25
  • Legacy Issue Number: 1904
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #4 REF: 1.9.4 Document Management

    How about viewer technology? Native and neutral images. Grouped files (i.e. 3d CAD models)?

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Manufacturing Implementation

  • Key: PDME-24
  • Legacy Issue Number: 1903
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #3 REF: 1.9.3 Manufacturing Implementation

    Is this just a BOM view by the MES? There could be much more here (ERP has one view; engineering another).

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

REF: 1.12.6 Develop Process Design and Procurement Agreements

  • Key: PDME-34
  • Legacy Issue Number: 1913
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #13 REF: 1.12.6 Develop Process Design and Procurement Agreements
    Procure Machine Tools, Firm Tools and Services
    Is this a workflow/ERP issue or a PDM issue?

    [May be within the scope of PDM if production tooling is tied to a part of assembly and is tracked by an engineering tool.]

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Differences in Purpose

  • Key: PDME-37
  • Legacy Issue Number: 1916
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #16 REF: 1.14.2.1.1 Differences in Purpose

    Modify bullets as follows:

    · Store (check in) and retrieve (check out) product "documents" and structures.

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Process - Part relationship

  • Key: PDME-69
  • Legacy Issue Number: 2152
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In the Manufacturing Implementation module there is a relationship between a
    ProcessRevision and the ProductRevisionChangeLevel. There is also a need for
    a relationship between the ProcessRevision and the
    Usage Relationship for defining Assembly Process Plans. This allows you to
    specify a Part specific process
    plan using the PartProducedByProcessRevision and Use this ProcessRevision to
    Usage relationship to specify
    Assembly Process plans.

  • Reported: PDME 1.0b1 — Fri, 30 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-68
  • Legacy Issue Number: 2151
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-67
  • Legacy Issue Number: 2150
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-66
  • Legacy Issue Number: 2149
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-60
  • Legacy Issue Number: 2143
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-59
  • Legacy Issue Number: 2142
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-64
  • Legacy Issue Number: 2147
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-63
  • Legacy Issue Number: 2146
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-62
  • Legacy Issue Number: 2145
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-61
  • Legacy Issue Number: 2144
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-58
  • Legacy Issue Number: 2141
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-57
  • Legacy Issue Number: 2140
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-56
  • Legacy Issue Number: 2139
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-55
  • Legacy Issue Number: 2138
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-65
  • Legacy Issue Number: 2148
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-54
  • Legacy Issue Number: 2137
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem creating certain objects

  • Key: PDME-41
  • Legacy Issue Number: 2101
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There"s a problem creating PartDataRelationship, PartDataIterationRelationship,
    PartStructureRelationship and PartStructureIterationRelationship objects.

    Unfortunately neither PartData nor PartStructure inherit from CosGraphs::Node
    in any way. This makes connecting a CosGraphs::Role-derived interface (like
    PartStructureOfPrcl) pretty difficult .

    I suggest to make both PartData and PartStructure inherit from
    PdmFramework::ManagedEntity. This would also provide the ability
    to add attributes and identifiers via the Attributable and Identifiable
    interfaces.

  • Reported: PDME 1.0b1 — Mon, 19 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Vault attributes shown as being read - write

  • Key: PDME-40
  • Legacy Issue Number: 1922
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The documentation describes the Vault attributes as
    being read only. The actual IDL code shows them
    as being read - write!

  • Reported: PDME 1.0b1 — Tue, 1 Sep 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.10.2 Level of control for Part manufacturing information

  • Key: PDME-43
  • Legacy Issue Number: 2124
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    2.10.2 Similarly, why do PRCLs reference ProcessRevisions direct not via their PartDataIterations? This relationship could be pushed down to the PartDataIteration level allowing closer tracking of the Manufacturing process for a Part. Paul J .

  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

1.14.1 Relationship to RM-ODP?

  • Key: PDME-42
  • Legacy Issue Number: 2123
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1.14.1 Should we at a later date define relationship to RM-ODP?

  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-53
  • Legacy Issue Number: 2135
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-52
  • Legacy Issue Number: 2134
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-49
  • Legacy Issue Number: 2131
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-48
  • Legacy Issue Number: 2130
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-45
  • Legacy Issue Number: 2127
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-44
  • Legacy Issue Number: 2125
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-51
  • Legacy Issue Number: 2133
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-50
  • Legacy Issue Number: 2132
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-47
  • Legacy Issue Number: 2129
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-46
  • Legacy Issue Number: 2128
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Thu, 29 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

PDM Enablers IDL uses different include file names than CORBA Services IDL

  • Key: PDME-18
  • Legacy Issue Number: 1769
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In "#include" statements, The IDL published in the PDM Enablers specification uses file names for most of the CORBA Services that are different than the file names used in "#include" statements by the CORBA Services IDL published on the OMG web site.

    For example, PdmResponsibility.idl has the following statement:
    #include <CosLifeCycle.idl>
    and the published IDL for Compound Life Cycle has
    #include <LifeCycle.idl>

    To compile PDM Enablers IDL with the published CORBA Services IDL, one of the sets of IDL needs to be hand-edited to be consistent with the other. The PDM Enablers IDL should be changed to be consistent with the published CORBA Services IDL. This problem originally arose because there are apparently no published official file names for the CORBA Services IDL files.
    .

  • Reported: PDME 1.0b1 — Mon, 3 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Configuration module: ProductRootToComponent - Relationship

  • Key: PDME-17
  • Legacy Issue Number: 1745
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: D) In the Configuration module, the ProductRootToComponent-Relationship should be changed to
    run from a ProductClass to a ProductComponent. We see the need to be able to freely associate
    ProductComponents to ProductClass definitions. Currently the ProductRootToComponent runs
    from ProductComponents only to ProductRootClasses, therefore causing heavy limitations.This
    relationship should also have it’s cardinality altered from currently 1:n to a more flexible m:n,
    allowing ProductComponents to appear in many ProductClasses, and to associate many
    ProductComponents to a ProductClass, which is how it is used by many of our customers
    especially from the automotive section.

  • Reported: PDME 1.0b1 — Mon, 27 Jul 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL consistency Issue for PDM

  • Key: PDME-11
  • Legacy Issue Number: 1643
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In the Salt Lake city meeting Ed brought up a point that Revisions
    cannot be created independent of the Master and the Iteration cannot
    be created independent of the Revision to which it belongs.

    As a result the Factory for the Master - to - Revision relationship
    does not exit and the create function for the revision takes the
    Master as a parameter and also creates the MasterRevision
    relationship. The same is also true for Revision to Iteration
    Relationship. eg BaselineRevisionFactory - The create function takes a
    BaselineMaster as a parameter and creates the
    BaselineMasterComposition Relationship.

    This behaviour has been duplicated in the Master-Revision-Iteration
    relationships of most of the modules expect the Product Structure
    Definition. In the ProductStructureDefinition Module the following
    relationships should not have factories:
    PartMasterComposition
    PartDataRelationship
    PartStructureRelationship
    PartDataIterationRelationship
    PartStructureIterationRelationship

    Taking this principle one step further we can say that this behaviour
    is true for all Containment Type of relationships (Black Diamond). If
    so then there are a few other places where this applies these are
    Change Management Module:
    Deliverable relationship
    ChangeDescription relationship

    Configuration Management Module
    SpecificationCategoryComposition Relationship

  • Reported: PDME 1.0b1 — Wed, 8 Jul 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: PDME-10
  • Legacy Issue Number: 1574
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Illegal usage of keyword "context"

  • Key: PDME-13
  • Legacy Issue Number: 1721
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The IDL shown in a few modules contain illegal usage of the
    keyword "context" and cases of type/variable names, which
    differ only incase. Both facts reperesent illegal IDL (but have
    only be detected by one compiler....).

  • Reported: PDME 1.0b1 — Wed, 22 Jul 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

PDM Enablers issue - PartDataFactory attributes

  • Key: PDME-12
  • Legacy Issue Number: 1708
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There are interfaces for PartData, and PartDataFactory in the PdmProductStructureDefinition module. A Client uses the PartDataFactory create operation to create a PartData object and give PartData object attributes. Once the attributes were add to PartData object, there is apparently no way for the client to get them out or change the attributes" value. The same issue exists for PartStructure too.

    It does not make much sense to assign attributes through the PartData and PartStructure interfaces. They are grouping and control interfaces which really exist only to provide separation between structure and data so that they can be separately iterated, and to provide navigation from PartRevisionChangeLevel and the different (two) types of iterations (PartDataIteration and PartStructureIteration).

    Notice that both PartRevisionChangeLevel and the PartIteration interfaces are all Attributable, so that Attributes are appropriately accessed through those interfaces

  • Reported: PDME 1.0b1 — Tue, 21 Jul 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add relationship from document master directly to vault

  • Key: PDME-15
  • Legacy Issue Number: 1743
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: B) Add a relationship from a DocumentMaster directly to a Vault with the corresponding document
    data. If the PdmEnablers are used for importing or exporting a partial model from one Pdm-
    System to another, there often will be only one file to import/export, and only in rare cases
    complete document-hierarchies will be exposed. With a direct relationship from DocumentMaster
    to a corresponding Vault there would be no need to build up the complete hierarchy for
    documents (Master, Revision, Iteration, File, Vault) if you want to expose only one single file,
    which could eliminate the creation of much overhead.

  • Reported: PDME 1.0b1 — Mon, 27 Jul 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change cardinality of ComponentHierarchy-Relationship

  • Key: PDME-14
  • Legacy Issue Number: 1742
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A) Change the cardinality of the ComponentHierarchy-Relationship from now 1:n to n:m. This
    would enhance the flexibility of use for ProductComponents significantly and would allow the
    creation of more complex hierarchies.

  • Reported: PDME 1.0b1 — Mon, 27 Jul 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add relationships from most main objects to documents

  • Key: PDME-16
  • Legacy Issue Number: 1744
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: C) Add relationships from most main objects to documents, especially from the Configuration,
    Changemanagement and Manufacturing module. In a real construction process, every single step
    and every configuration needs to be properly documented. In most main elements (ItemSolution,
    ProductComponent, ProductFunction etc.) there is only one field ”description”, which cannot
    fulfill the need for complete documentation. Therefore we suggest relationships from
    DocumentMasters to: ItemSolution, ProductComponent, ProductClass, ProductFunction,
    Specification, Configuration (from Configuration module), to ProcessStep (from Manufacturing)
    and to EngChangeItem, EngChangeRequest, EngChangeOrder (from Change management). A
    technically correct way for these changes would be the creation of an new Interface
    ”Documentable” from which all main elements would inherit (like they do from Qualifiable or
    Attributable) and to have a single relationship from the DocumentMaster to the ”Documentable”
    object, simultaniously eliminating all specialised relationships to and from DocumentMaster or
    DocumentRevision.

  • Reported: PDME 1.0b1 — Mon, 27 Jul 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Engineering Change Order

  • Key: PDME-23
  • Legacy Issue Number: 1902
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #2 REF: 1.9.2 Engineering Change Order

    This design implies a two step ECM process model (ECR à ECO). While rare, not all organization use this strategy. Some employ a one-step method (no ECR; go straight to ECO).

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial changes to mfg/98-02-02

  • Key: PDME-22
  • Legacy Issue Number: 1901
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ISSUE #1 - Editorial changes

    1.) 1.10.2.1, p. 15: change "CosLifeCycle LifeCycleObject" to "CosLifeCycle::LifeCycleObject
    2.) 1.14.2.2.1, p.39: need separation between paragraphs
    3.) 2.7.3.4, p. 136: change "PartRevisionChangeLeve" to "PartRevisionChangeLevel"
    4.) 2.11.1: The model name is "Camry", not "Camary". In either event, it is trademarked and probably should be so noted.

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Alignment of OMG Person/Party models

  • Key: PDME-21
  • Legacy Issue Number: 1895
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: There are differences between the interfaces for Person in
    the PdmResponsibility module and in the PIDS. In general, these two
    models reflect different concerns for the management of Person
    and Party objects, but they have identifiably common attributes
    that will also no doubt be part of any Party Management proposal,
    which we may expect to be implemented by Human Resource Management
    systems. Because of the coupling of Human Resource Management with
    PDM and ERP systems in the manufacturing operations environment, it will
    be necessary for Manufacturing to have a common basis model for Person
    and Party that extends across these systems. An initial cleanup of
    unnecessary nomenclature differences will facilitate this.

  • Reported: PDME 1.0b1 — Thu, 27 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Duplicate Exceptions

  • Key: PDME-19
  • Legacy Issue Number: 1800
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It seems that
    there are a few cases where duplicate exceptions
    are being raised. The c++ compiler recognizes this
    as a warning. Nothing major here but it does
    cause lots of warnings during the compiles.

  • Reported: PDME 1.0b1 — Wed, 12 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

No City in PdmResponsibility

  • Key: PDME-20
  • Legacy Issue Number: 1801
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In the PdmResponsiblity module, there is no
    attribute for "City". Probably ought to go in the Party
    interface.

  • Reported: PDME 1.0b1 — Wed, 12 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

IdentificationContext Considered Harmful

  • Key: PDME-99
  • Legacy Issue Number: 4161
  • Status: open  
  • Source: NIST ( David Flater)
  • Summary:

    Problem:
    1. Confused "context" with "scope"
    The spec muddles the following two things together:

    • The need to maintain multiple identifiers for a single entity in different contexts: this Widget is known as Navy Part X, and
      also as Company Part Y. This is a user-level, real-world, business concept.
    • The need to qualify the identifiers of different entities based on their scopes: Document X is not the same entity as Part X,
      and Revision Z of Document X is not the same entity as Revision Z of Document Y. This is an implementation-level concept.
      Conceptually, the scoping of identifiers occurs within a context, but the spec requires us to create separate
      IdentificationContexts for every scope.
      A special case was made to allow Revisions to be implicitly scoped by their Master (Section 2.3.3.6, just above Implementation
      Issues). This is even worse because it violates the model of identification. An identifier is supposed to uniquely specify an
      entity within a context. If a Revision cannot be unambiguously retrieved using only a context and an identifier, then Revision
      should not inherit from Identifiable.
      If Revisions are identifiable, then their identifications probably consist of a revision number qualified by a path to the
      Master or by some other information that is sufficient to identify the scope. That is not to say that a user interface would
      force the user to specify anything more than the revision number once the scope of that session has been established. This is
      similar to the usage of relative path names in a file system. But in the current spec, a Revision is like some weird, special
      kind of file that exists within its directory if you go there first but cannot ever be accessed using a fully-qualified path.
      Consider the ramifications for application programmers.
      2. High overhead
      A consequence of muddling scope with context is the proliferation of IdentificationContexts. A large number of these must be
      propagated into the Bill of Materials and retrieved and managed by every client program, no matter what the application. This
      creates special problems for query and traversal convenience functions because there is no convenient way to specify all of the
      needed IdentificationContexts.
      Alternately, in the case of implicit scoping, clients are unable to retrieve certain entities based on their identifications
      alone and must instead navigate from entities whose identifications are unambiguous. The client is forced to manage additional
      information and perform extra operations because the PDM does not maintain the uniqueness of identifiers. Clients should not be
      required to navigate to something that is Identifiable; they should be able to do a simple find-by-ID if an ID is what they've
      got.
      3. Interoperable client not feasible
      A client cannot rely on find_id_context to locate a usable IdentificationContext without special knowledge about the
      implementation because both the existence of a default context and the set of kinds that have associated IdentificationContexts
      are implementation-dependent. Instead, an interoperable client must use find_id_contexts to retrieve a list of candidate
      IdentificationContexts for each interface type and then select among the candidates. The client is trying assemble the
      collection of IdentificationContexts that would correspond to a single context if scope and context were not intermingled. But
      since they are, there is no interoperable way to determine which set of IdentificationContexts is appropriate.
      If the client should luck into an appropriate set of IdentificationContexts, it still must somehow discover and conform to the
      implementation-dependent rules for the properties to pass to generate_id. There does not seem to be any interoperable way to do
      this either.
      4. Implementation details are exposed
      The vendor's decision to use a single name space for all PDM objects or to use separate name spaces for every class of objects
      internal to the PDM is an implementation detail that need not be exposed and should not be exposed.
      Under the current spec, clients have the unenviable job of discovering and conforming to the internal name space structure of
      the PDM. They do not really benefit from the standardization of the interface because the behavior is still different for each
      implementation. Instead, the implementation details of identifications should be factored out of the standard interface.

    Proposed changes:

    1. Replace the first paragraph of Section 2.3.3.5 with the following: "The IdentificationContext object represents the business
    context in which object identifications apply and the identification formats and rules that apply in that context. For example,
    an identification context may define Navy part numbers and generate identifications conforming to the formatting and rules that
    the Navy and the PDM require. Different contexts can be defined for different government agencies, vendors, or even internal
    divisions."
    2. Replace the first line of IDL with the following:
    typedef string IdentificationContextName;
    3. Add the operation CosPropertyService::PropertySet IdentificationContext::get_properties().
    4. Delete the operation IdentificationContextFactory::find_id_contexts.
    5. Delete all text between the IDL (starting with "Implementations...") and find.
    6. Add the following description of get_properties(): "Returns a PropertySet indicating the names of the properties that are
    required to generate a valid identifier in the current context. Default values may be supplied for some or all of the
    properties. The client should fill in the values of the properties and then pass the filled-in PropertySet to generate_id.
    7. Append the following text to the description of find_id_context: "The the_context_name parameter specifies the
    business-related name. If the implementation supports a default identification context or only one identification context, the
    default name is represented by the empty string (that is, a string of length 0)."
    8. In Factory operations, delete the operation find_id_contexts.
    9. In Section 2.3.3.6 Design, insert the following text as a new first paragraph: "A context represents a user-level,
    real-world, business entity. It is entirely separate from any name space hierarchy and/or nomenclature rules that may exist
    internal to the PDM implementation. Contrariwise, an IdentifierSeq is specifically intended to encapsulate the
    implementation-dependent aspects of identification and may be used in whatever manner is most convenient to the implementor. An
    arbitrary number of internal name spaces may be navigated using arbitrarily detailed IdentifierSeqs."
    Append the following text at the end of what is currently the first paragraph: "...in some way. However, specific
    interpretations of the content of an IdentifierSeq or identifier string are not within the scope of this standard. For maximum
    interoperability, a PDM client should treat the IdentifierSeq as an illegible database key and the identifier string as
    derivative text intended for presentation purposes only."
    10. Delete Figure 2-1 and the paragraph that refers to it.
    11. Retain Figure 2-2 and the paragraph that refers to it.
    12. Delete Figure 2-3 and the remaining two paragraphs leading up to Implementation Issues.
    13. In Implementation Issues, insert the following text as a new paragraph between the current first and second paragraphs:
    "Customizability is also an important product differentiator. Internally, an implementation might support separate name spaces
    for each descendant of Identifiable. A customer's part numbering system may be different from their document numbering system,
    and their ECO numbering system will likely be different from those of parts and documents. These are trivially mapped to a
    single name space per context by using the first component of the IdentifierSeq to select the name space, with the remaining
    components conforming to the customer-dependent rules for that name space. This enables interoperable clients to achieve a
    useful level of functionality treating the IdentifierSeq as an illegible database key while customized clients can interpret the
    contents of the IdentifierSeq according to the needs of each customer."

  • Reported: PDME 1.0b2 — Fri, 19 Jan 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

PDM RTF issue: "successor"

  • Key: PDME-98
  • Legacy Issue Number: 4148
  • Status: open  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    As documented in 2.4.3.20, Supersedes is a RevisionMaster relationship that represents the decision to "roll part number" in
    implementing a part revision. That is, it represents the replacement of a previous rev, e.g. 1234-C-1, with a new Part, e.g.
    1255(-A-1). But the most common RevisionRelationship, also sometimes called "supersedes", is what happens when 1234-D replaces
    1234-C. That relationship is actually modelled by the relationship called "successor" that is a documented subtype of "Derive"
    (2.4.3.17), and is a relationship between ItemIterations (which is correct). But the other subtypes of Derive ("copied" and
    "translated") have significantly different semantics, implying a continuing dependency on the original. Successor, especially
    as it relates to ECNs, does not implicitly have this property: 1234-D-3 may be the new baseline, successor to 1234-C-4.
    Successor should be an explicit subtype of IterationRelationship (at the same level of visibility as Dependency and Derive) in
    the PdmFramework.

    Note for the RTF: I am raising this as an issue to be discussed, but I'm not convinced we want to make a change. First, this
    change could be disruptive to existing implementations. Second, if you have a base part design pending approval and start a set
    of serial-number-specific variants of the base part (truly "derived" iterations) and the base part design is not approved and
    acquires a "successor", you want to retrofit the changes in the base part (the "successor") to the variants. And that is a
    "convenience function" that follows the "successor" relationship backward and then the transitive closure of the Derive
    relationships forward, including successor iterations of the derivative variants. I assume that is why the model works the way
    it does. It may be that the ECO/ECN "successor"/"supersedes" relationship is actually a different relationship!

  • Reported: PDME 1.0b2 — Thu, 11 Jan 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

"interface name" is ambiguous

  • Key: PDME-97
  • Legacy Issue Number: 4131
  • Status: open  
  • Source: NIST ( David Flater)
  • Summary:

    This issue references formal/2000-06-18, Life Cycle Service V1.1

    In Table 2-1 in Section 2.1.2.1 (find_factories), replace "name of
    object interface" with "RepositoryId of object interface" and "name of
    factory interface" with "RepositoryId of factory interface."

    In Table 2-2 in Section 2.1.3.1 (create_object), replace "name of
    object interface" with "RepositoryId of object interface."

    [With respect to "name of object implementation" and "name of
    equivalent implementations," I do not know what the intent was.
    PortableServer::ObjectId might be appropriate for the former?]

  • Reported: PDME 1.0b2 — Wed, 27 Dec 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Vault object references

  • Key: PDME-94
  • Legacy Issue Number: 3301
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    The current PDM Enablers standard provides a mechanism for obtaining object references to Vaults. In order to obtain an object reference the client must perform a ‘find’ operation on PdmDocumentManagement::VaultFactory. The operation requires the client to submit a vault_id as an input parameter to the ‘find’ operation.
    This mechanism makes it difficult, if not impossible, to obtain references to vaults which ID’s are not known to the client. Also, it is cumbersome when references to several vaults are required.
    The PdmDocumentManagement::VaultFactory interface could be extended by an introduction of a new operation, say ‘get_vaults()’ that takes no input parameters and returns a sequence of PdmDocumentManagement::Vault object references.

  • Reported: PDME 1.0b2 — Mon, 7 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Convention for Creating Items

  • Key: PDME-93
  • Legacy Issue Number: 3090
  • Status: open  
  • Source: Hewlett-Packard ( Duane Silkworth)
  • Summary:

    The PDM Enablers defines factory interfaces to create objects but the inputs and results of the create operations are weakly specified.

    Each create operation takes a property set as a parameter, but the list of properties required is not fully specified. Note that site-specific business rules may dictate the names and values of required properties. To enable interoperability, though, it would be helpful for the specification to dictate that no unspecified properties be required, and that unspecified properties should default to reasonable values depending on the site’s business requirements. It would also be helpful to specify the name of a property to determine the sub-type of the item to be created, where applicable.

    The allowed side effects of each create operation should be specified in as complete a manner as possible. For example, is it legal for the PartMaster create operation to implicitly create persistent objects that support other interfaces such as the PartRevision or PartDataIteration?

  • Reported: PDME 1.0b2 — Mon, 29 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Attributes

  • Key: PDME-92
  • Legacy Issue Number: 3086
  • Status: open  
  • Source: Hewlett-Packard ( Duane Silkworth)
  • Summary:

    The PDM Enablers specify a generic computational model that can be used to access and manipulate information according to a wide variety of detailed information models. In order to interoperate completely, clients and servers must agree on both the computational model and the information model. It is important that the PDM Enablers computational interfaces remain generic and flexible so that they can be used with any site’s proprietary information model and business processes.

  • Reported: PDME 1.0b2 — Mon, 29 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change name DocumentRevisionRelationship to PartDocumentRelationship

  • Key: PDME-91
  • Legacy Issue Number: 2438
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: The name DocumentRevisionRelationship is misleading in that it has
    nothing to do with revising Document objects per se, and it does not
    inherit from RevisionRelationship (2.3.14) as one might expect.
    Moreover, this relationship is one of three ways of characterising
    a PartRevisionChangeLevel – by Document, by Data set and by Structure.
    The other two are called PartDataRelationship and PartStructureRelationship.
    This one should be called PartDocumentRelationship.

  • Reported: PDME 1.0b1 — Thu, 4 Feb 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

allow "document type" to be the IdContext "kind"

  • Key: PDME-96
  • Legacy Issue Number: 4027
  • Status: open  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The class "Document" is not necessarily a useful "object category" for name
    scoping. Documents have
    company-standard or even industry-standard "types", e.g. "structures model" or
    "piping model", and those are the types of the "business objects" inside the
    PDM. Company document naming conventions may focus on "document type". E.g.
    "Geometric-model, 12345-1" and "Type3-load-analysis, 12345-1" may be unique
    names for different DocumentMasters, whereas "DocumentMaster, 12345-1" doesn't
    name anything. But "PartMaster, 12345-1" does, because "Part(Master)",
    "Geometry-model" and "Type3-load-analysis" are the "business objects".

  • Reported: PDME 1.0b2 — Wed, 8 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ConfigurationItem

  • Key: PDME-95
  • Legacy Issue Number: 3311
  • Status: open  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

    Description:
    No factory does exist for this non abstract interface. How is a
    ConfigurationItem constructed?

  • Reported: PDME 1.0b2 — Thu, 10 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure needs updates

  • Key: PDME-90
  • Legacy Issue Number: 2360
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Figure needs updates (related to Issue 9?)

  • Reported: PDME 1.0b1 — Fri, 29 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 1 in section "2.2.3.5.1" has two incorrect object names

  • Key: PDME-89
  • Legacy Issue Number: 2359
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Figure 1 in section "2.2.3.5.1 Additional Identification Description" has two incorrect object names.
    Part Description text indicates discrete mfg, how could this be expanded for larger industry in the future.. 2.7.1 Part description is targeted towards descrete manufacturing, can it be expanded to other industry areas
    .

  • Reported: PDME 1.0b1 — Fri, 29 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Part Description text indicates discrete mfg,

  • Key: PDME-88
  • Legacy Issue Number: 2257
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Part Description text indicates discrete mfg, how could this be expanded for larger industry in the future.. 2.7.1 Part description is targeted towards descrete manufacturing, can it be expanded to other industry areas

  • Reported: PDME 1.0b1 — Tue, 15 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

PdmDocumentManagement IDL is obsolete

  • Key: PDME-87
  • Legacy Issue Number: 2250
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In the convenience document mfg/98-02-02, the IDL for PdmDocumentManagement is obsolete, and does not match the adopted IDL file specified in the errata document mfg/98-02-01.

  • Reported: PDME 1.0b1 — Mon, 7 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

PDM Enablers shall support use of a Note Object

  • Key: PDME-1
  • Legacy Issue Number: 1546
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1. PDM Enablers shall support use of a Note Object. Note Object(s) are used by Boeing to store note text associated with another Object (e.g. Documents, Models, Parts, Processes, etc.). Notes may provide information about how to handle, fabricate, or process a part that is not contained in any other location (e.g. a Definition or Process Note may be created for a graphics model), or notes may provide additional information pertaining to a Work Authorization. Note Records are revision controlled and are linked to the Object types to which they correspond. Boeing PDM provides the capability of resolving where the Note is used in a product structure relationship. Notes may contain attributes as described in the following table (for example only):

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Note Objects currently not addressed

  • Key: PDME-6
  • Legacy Issue Number: 1560
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: PDM Enablers do not currently address Note Objects. This is a Boeing Requirement.

    Disposition: Submit as Boeing Requirement to be supported by PDM Enablers

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

How can we extend ICOM

  • Key: PDME-5
  • Legacy Issue Number: 1556
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: How do we extend ICOM? Keep PDM Enablers add attributes vs. Subtyping PDM Enablers?

    Disposition:

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

What Security Systems are used with the PDM Enablers?

  • Key: PDME-9
  • Legacy Issue Number: 1573
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What security services are to be used with the PDM Enablers? CORBA Security Services?

    Disposition:

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of PDM Enablers.

  • Key: PDME-8
  • Legacy Issue Number: 1572
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When does one use OMG PDM Enablers and when does one use STEP PDM Schema?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

IdentificationContext appears not to be value added

  • Key: PDME-2
  • Legacy Issue Number: 1548
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: IdentificationContext appears to be no value added. Boeing only wants to make call to get Partid without overhead baggage attached. There exists limited to no capability for query functionality.

    Disposition:

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Identify cases where interoperability between PDM systems is of use

  • Key: PDME-3
  • Legacy Issue Number: 1552
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Identify cases where interoperability between PDM Systems would be of use. Identify how these PDM Systems interoperating would be supported by PDM Enabler Functions

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of PDM Enablers without modifying them

  • Key: PDME-4
  • Legacy Issue Number: 1554
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Can we build Boeing ICOM and use PDM Enablers without modifying PDM Enablers?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Document and/or Drawing Sheet Information

  • Key: PDME-7
  • Legacy Issue Number: 1562
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: How do we handle Document and/or Drawing Sheet Information in PDMEnablers?

    Disposition:

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT