Product Data Management Enablers Avatar
  1. OMG Specification

Product Data Management Enablers — All Issues

  • Acronym: PDME
  • Issues Count: 59
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
PDME12-4 PdmChangeManagement (page 2-150) PDME 1.0b2 PDME 1.2 Resolved closed
PDME12-3 PdmContext is insufficient as a TraversalCriteria PDME 1.0b2 PDME 1.2 Resolved closed
PDME14-6 PdmChangeManagement (page 2-150) PDME 1.3 PDME 1.4 Resolved closed
PDME14-5 PdmDocumentManagement (page 2-93) PDME 1.3 PDME 1.4 Resolved closed
PDME14-3 PdmFramework Entity Model (page 2-51) PDME 1.3 PDME 1.4 Resolved closed
PDME14-2 Some wording - the last paragraph on page 2-34 is wrong PDME 1.3 PDME 1.4 Resolved closed
PDME14-1 PdmFoundation Model (page 2-26) PDME 1.3 PDME 1.4 Resolved closed
PDME14-4 PdmViews Model (page 2-79) PDME 1.3 PDME 1.4 Resolved closed
PDME12-2 PDM RTF Issue - The Identifiable interface should raise InvalidProperties PDME 1.0b2 PDME 1.2 Resolved closed
PDME12-1 PDM Enablers - cannot determine client type for file transfer PDME 1.0b2 PDME 1.2 Resolved closed
PDME14-15 was/is relationships to The EngChangeAffectedData relationship PDME 1.3 PDME 1.4 Resolved closed
PDME14-14 make_buy missing in IDL PDME 1.3 PDME 1.4 Resolved closed
PDME14-8 PdmFoundation.idl version 1.3, dtc/00-10-01 PDME 1.3 PDME 1.4 Resolved closed
PDME14-7 addition of two exceptions to CosGraphs::Node::add_role(). PDME 1.3 PDME 1.4 Resolved closed
PDME14-17 Is Transactionable still needed? PDME 1.3 PDME 1.4 Resolved closed
PDME14-16 ObjectChangeNotification models the "is" PDME 1.3 PDME 1.4 Resolved closed
PDME14-10 allow Documentable to point to a DocumentRevision or a DocumentMaster. PDME 1.3 PDME 1.4 Resolved closed
PDME14-9 move Qualifiable up to EngChangeItem. PDME 1.3 PDME 1.4 Resolved closed
PDME14-18 Provide an ID when creating an object PDME 1.3 PDME 1.4 Resolved closed
PDME14-13 "interface repository name" is an undefined term. PDME 1.3 PDME 1.4 Resolved closed
PDME14-12 missing attribute in the IDL PDME 1.3 PDME 1.4 Resolved closed
PDME14-19 Should all PDM Enablers IDL files begin with #pragma prefix "omg.org" PDME 1.3 PDME 1.4 Resolved closed
PDME14-11 Interactions to be specified PDME 1.3 PDME 1.4 Resolved closed
PDME13-6 PdmContext is insufficient as a TraversalCriteria PDME 1.2 PDME 1.3 Resolved closed
PDME13-5 IdentificationContext Conventions PDME 1.2 PDME 1.3 Resolved closed
PDME13-2 Authentication PDME 1.2 PDME 1.3 Resolved closed
PDME13-1 Session Management PDME 1.2 PDME 1.3 Resolved closed
PDME13-4 Factory Finder Conventions PDME 1.2 PDME 1.3 Resolved closed
PDME13-3 Workflow PDME 1.2 PDME 1.3 Resolved closed
PDME13-8 Factories to non-abstract subtypes of Effectivity PDME 1.2 PDME 1.3 Resolved closed
PDME13-7 Factories for non-abstract subtypes of Qualification PDME 1.2 PDME 1.3 Resolved closed
PDME13-9 ViewQualification is abstract PDME 1.2 PDME 1.3 Resolved closed
PDME-122 How does a PDM Enabler server expect the format of wild cards? PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-121 Default for all systems needed PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-106 Provide Data Dictionary PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-105 Engineering change document needed PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-116 How do PDM Enablesr identify specific part not knowing specific context PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-115 specific queries PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-108 Modularity PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-107 Need capability to return list Generalized Find (Query) capabilities PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-110 DesignMakeFrom relationship, and DMFR Substitute PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-109 How should PDM relate to Workflow? PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-118 Are contexts meant to be the same across PDM Systems? PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-117 Can client be written to retrieve a part from multiple PDM systems? PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-114 Structured Documentation Capability provided? PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-113 PDM_Image and PDM_Markup PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-120 How are argument formats for a query to be specified? PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-119 How are defaults to be specified? PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-112 How are models accommodated in PDM Enablers? PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-111 How do PDM Enablers accommodate Alternate/Substitute Part ranking? PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-130 Make certain ConfigurationManagement interfaces Documentable PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-129 Subprocesses in section 1.12.7 and 1.12.9, that have been addressed by 2.9 PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-131 PDM Enablers file locking behavior PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-124 PersonOrganization Issue PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-123 PersonOrganization relastionship -- IDL problem PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-126 1.14.2.2.1 management of STEP Data PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-125 ISSUE #17 REF: 1.14.2.1.5 Versioning PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-128 There is no way to find or navigate to a PdmDocumentManagement::Vault inte PDME 1.0b1 PDME 1.0b2 Resolved closed
PDME-127 There are some bugs in the AssemblyComponentUsage PDME 1.0b1 PDME 1.0b2 Resolved closed

Issues Descriptions

PdmChangeManagement (page 2-150)

  • Key: PDME12-4
  • Legacy Issue Number: 3761
  • Status: closed  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

    6. PdmChangeManagement (page 2-150)
    EngChangeItem should have a attribute "description" of type string,
    according to
    the specification.
    Remark: I am not sure, is this the intent of resolving issue 1744
    (compare
    issue 2150 for the Views-Module)? May be, we need some more changes in
    the
    IDL snippet, in the explanation to EngChangeItem and in the IDL of
    PdmChangeManagement.

  • Reported: PDME 1.0b2 — Thu, 20 Jul 2000 04:00 GMT
  • Disposition: Resolved — PDME 1.2
  • Disposition Summary:

    Duplicate from issue 3760, clos eissue

  • Updated: Sun, 8 Mar 2015 18:39 GMT

PdmContext is insufficient as a TraversalCriteria

  • Key: PDME12-3
  • Legacy Issue Number: 3155
  • 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.0b2 — Tue, 21 Dec 1999 05:00 GMT
  • Disposition: Resolved — PDME 1.2
  • Disposition Summary:

    Duplicate of 3154. Closed

  • Updated: Sun, 8 Mar 2015 18:22 GMT

PdmChangeManagement (page 2-150)

  • Key: PDME14-6
  • Legacy Issue Number: 3760
  • Status: closed  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

    6. PdmChangeManagement (page 2-150)
    EngChangeItem should have a attribute "description" of type string,
    according to
    the specification.
    Remark: I am not sure, is this the intent of resolving issue 1744
    (compare
    issue 2150 for the Views-Module)? May be, we need some more changes in
    the
    IDL snippet, in the explanation to EngChangeItem and in the IDL of
    PdmChangeManagement.

  • Reported: PDME 1.3 — Thu, 20 Jul 2000 04:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    No Data Available

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

PdmDocumentManagement (page 2-93)

  • Key: PDME14-5
  • Legacy Issue Number: 3759
  • Status: closed  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

    5. PdmDocumentManagement (page 2-93)
    File has exactly one attribute "name" of type string.
    Vault attribute "id" is readonly.
    This is wrong in the IDL snippet on page 2-97. The wording in the last
    paragraph
    on page 2-97 is correct.

  • Reported: PDME 1.3 — Thu, 20 Jul 2000 04:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    see below

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

PdmFramework Entity Model (page 2-51)

  • Key: PDME14-3
  • Legacy Issue Number: 3757
  • Status: closed  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

    3. PdmFramework Entity Model (page 2-51)
    Attributable has a function "get_updatable_info" (not
    "get_updateable_info", although
    my spell checker corrects the form used throughout the specification to
    the UML notation 8-

  • Reported: PDME 1.3 — Thu, 20 Jul 2000 04:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    see below

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

Some wording - the last paragraph on page 2-34 is wrong

  • Key: PDME14-2
  • Legacy Issue Number: 3756
  • Status: closed  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

    2. Some wording - the last paragraph on page 2-34 is wrong
    "Examples of Identifiable are Part Master, Document Master, Document
    Revision, ECO,
    Person and Organization. For example, company name, cage code, Dun &
    Bradstreet
    number, or all of the above depending on the context may identify a
    company."

    Correct is: Person and Organization are not Identifiable! (This is very
    sad, it would be
    nicer they would be, but the authors expected this module to be replaced
    by another
    Corba spec).
    Proposal for formulation:
    "Examples of Identifiable are Part Master, Document Master, Document
    Revision and ECO. For example, cage code, Dun & Bradstreet
    number, or all of the above depending on the context may identify an
    entity.

  • Reported: PDME 1.3 — Thu, 20 Jul 2000 04:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    Change text

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

PdmFoundation Model (page 2-26)

  • Key: PDME14-1
  • Legacy Issue Number: 3755
  • Status: closed  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

    1. PdmFoundation Model (page 2-26)
    IdentificationContext has an attribute "id" of type
    "IdentificationContextName" (RTF 1.3)
    Identification has only a readonly attribute
    LockOwner has only readonly attributes
    ObjectClassification is named "ObjectSecurityClassification"
    ObjectSecurityClassification has an attribute "owner" of type "Person"

  • Reported: PDME 1.3 — Thu, 20 Jul 2000 04:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    Correct UML.

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

PdmViews Model (page 2-79)

  • Key: PDME14-4
  • Legacy Issue Number: 3758
  • Status: closed  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

    4. PdmViews Model (page 2-79)
    Factory interfaces are not part the other UML diagrams. Why is
    PdmTraversalCriteriaFactory shown at all?
    ViewQualification has exactly one attribute "name" of type string.
    BTW: ViewQualification is wrong in 00-06-03::PdmViews.idl (Manfred, you
    may correct this!)

  • Reported: PDME 1.3 — Thu, 20 Jul 2000 04:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    see below

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

PDM RTF Issue - The Identifiable interface should raise InvalidProperties

  • Key: PDME12-2
  • Legacy Issue Number: 2874
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Identifiable interfaces should be able to raise InvalidProperties exceptions.

    The PdmFoundation operations Identifiable::change_id and IdentificationContext::generate_id both take a property_set parameter but, unlike other operations that use PropertySets, they are not defined to raise the InvalidProperties exception.

    This is a minor issue. In the interim, implementations can raise the ValidationError exception if the property_set is invalid.

  • Reported: PDME 1.0b2 — Wed, 1 Sep 1999 04:00 GMT
  • Disposition: Resolved — PDME 1.2
  • Disposition Summary:

    resolved in 1.2 RTF

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

PDM Enablers - cannot determine client type for file transfer

  • Key: PDME12-1
  • Legacy Issue Number: 2622
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the PdmDocumentManagement module, the SecuredFile interface defines operations begin_put_buffer and begin_get_buffer to initiate file content transfers. Each of these operation has a transfer_encoding parameter to determine whther the transfer should proceed in a straight "binary" mode, or in an "8-bit" character/text mode. In 8-bit mode, between UNIX and MS Windows machines, the buffer transfer operations should adjust the end-of-line CR/LF bytes in the file according to the platform conventions. However, there is no defined way for the server to know what type of platform the client is.

    The begin_put_buffer and begin_get_buffer operations should have a parameter to tell the server what type of platform the client is.

  • Reported: PDME 1.0b2 — Tue, 27 Apr 1999 04:00 GMT
  • Disposition: Resolved — PDME 1.2
  • Disposition Summary:

    resolved by 1.2 RTF

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

was/is relationships to The EngChangeAffectedData relationship

  • Key: PDME14-15
  • Legacy Issue Number: 4146
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification: PDM Enablers v1.3 clause 2.10.3.16
    Source: Ted Briggs, Intergraph (SC4 AP227 project)
    Problem: To support the capture of the was/is relationships to The EngChangeAffectedData relationship should have two explicit
    attributes:
    -type, which is the "role" of the Changeable item affected by the change, e.g. starting revision of target part, technical
    manual, manufacturing fixture, manufacturing process, reference process, fit requirement, etc. This is important for Issues and
    ECRs that are in some state of development and for high-level ECRs that are issued but require refinement to specific
    work-orders.
    -status, which may be the current "disposition", which reflects the status of management decisions about the relationship of the
    ECI (particularly issues and ECRs) to that item, e.g. tentative, pending, approved, obsoletes, etc. This is particularly useful
    when the Changeable is qualified by Serial or Lot numbers, some of which may be firm, while others are questionable and may
    subsequently be deleted from the list. The current text suggests values of "disposition" that seem to be suitable only for
    ECNs.
    Also, EngChangeAffectedItem is the preferred nomenclature: it is usually a Part, Document or Process, all of which are
    ItemRevisions, and ItemRevision seems to be the only class that inherits from Changeable.

  • Reported: PDME 1.3 — Thu, 11 Jan 2001 05:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    see below

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

make_buy missing in IDL

  • Key: PDME14-14
  • Legacy Issue Number: 4145
  • Status: closed  
  • Source: PROSTEP AG ( Lutz Laemmer)
  • Summary:

    Edit directions against formal/2000-11-11 (PDM enablers spec)
    p. 8-18:
    PartDataIteration should have Attribute
    attribute string make_buy;
    (compare p. 8-8)

    Edit direction applies to
    formal/00-10-65 (PDM enablers 1.3 compilable IDL)
    as well - change PartDataIteration definition in
    PdmProductStructureDefinition.idl

  • Reported: PDME 1.3 — Thu, 11 Jan 2001 05:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    see above

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

PdmFoundation.idl version 1.3, dtc/00-10-01

  • Key: PDME14-8
  • Legacy Issue Number: 3992
  • Status: closed  
  • Source: NIST ( Mr. David Flater)
  • Summary:

    The exception PdmFoundation::ValidationError is included twice in the
    raises list of PdmFoundation::IdentificationContext::verify_id, once
    directly and once via PDM_EXCEPTIONS. Using JacORB 1.2.1 and Java 2
    SDK 1.3.0, the following compilation error results:

    IdentificationContextPOA.java:349: exception PdmFoundation.ValidationError has already been caught

    Proposed fix: remove the direct reference.

  • Reported: PDME 1.3 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    accepted as proposed

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

addition of two exceptions to CosGraphs::Node::add_role().

  • Key: PDME14-7
  • Legacy Issue Number: 3804
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    If I understand correctly, you are asking for the addition of two
    exceptions to CosGraphs::Node::add_role().

    1. The exception DuplicateRole shall be thrown when add_role() is
    invoked to add a Role of the "same type" as an existing Role of the same
    Node, WHERE the Role is constrained to be uniquely assumed by that Node
    by constraints provided to the CosGraphs implementation. "same type"
    means:

    • a Role with the same interface type,
    • a Role whose interface type is a supertype of the given role, or
    • a Role whose interface type is a subtype of the given Role.
      (Technically that would have to be stated in terms of the CORBA::is_a
      operation.)

    2. The exception InappropriateRole shall be thrown when add_role() is
    invoked to add a Role to a Node that is not an admissible Role for that
    Node per some constraints provided to the CosGraphs implementation.

    And you are asking for the further statements in the PDM Enablers that

    3. All PDM Enablers Roles shall be uniquely assumed.

    4. The PDM Enablers relationship definitions shall be interpreted as
    specifying the complete set of Role types that may be assumed by a PDM
    Enablers interface that inherits from Node.

    Is this the correct interpretation of your issues? If not, can you make
    clear exactly what you want to change in CosGraphs and PDM Enablers?

    Notes:

    1. Making these changes to Node::add_role() would require changing
    CosGraphs first, and then the PDM Enablers. These are separate OMG
    standards (maintained by different Task Forces and TCs) and two separate
    "revision activities" would be required. At the moment, there is no
    active RTF for CosRelationships (including CosGraphs), and we would have
    to create such an activity first. (There is an active RTF for PDM
    Enablers, and Lutz Lämmer and I chair it.)

    2. CosGraphs itself does not require either of these "constrained
    interpretations", and it is not clear that it provides any means of
    stating the constraints that would be used to throw the exceptions. I
    don't think that one necessarily has to provide the means in order to
    provide the exception. Things like PDME that inherit from CosGraphs
    interfaces can provide the means.

    3. We do have to distinguish between the "cardinality of Role
    assumption" and the "cardinality of Relationship participation". That
    is, if a PartMaster can have many PartRevisions and thus many
    PartMasterComposition relationships, does the PartMaster as Node have

    • one PartMastertoPartRevision Role for each PartMasterComposition
      relationship in which it participates (so that the Role object is unique
      to the Relationship object), or
    • one PartMastertoPartRevision Role for all PartMasterComposition
      relationships in which it participates (so that the Role object is
      unique to the Node object)?

    In the general case, where a Role object may have its own attributes and
    operations, either of these is possible, but they reflect different
    semantics for the attributes/operations of the Role. So CosGraphs
    itself should not require either behavior exclusively. In the
    particular case of the PDM Enablers, no Role object is defined to have
    additional attributes and operations, so the choice is arbitrary, and we
    may want to impose a standard convention. However, a PDM Enablers
    implementation may need to impose additional internal attributes and
    operations on its internal representation of the Role objects, and for
    that implementation the choice is no longer arbitrary. Thus it is
    necessary for all implementors to agree on a particular standard
    convention. I take it that UG would like to standardize the second
    convention above. Does anyone take issue with this?

  • Reported: PDME 1.3 — Wed, 6 Sep 2000 04:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    see above

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

Is Transactionable still needed?

  • Key: PDME14-17
  • Legacy Issue Number: 4162
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    Summary:
    With the recent changes to the Object Transaction Services, it does not appear that there is any interface for a
    "transactionable" object to inherit from. The Transactionable interface was intended to provide that inheritance for the
    previous version of the OTS. It no longer serves a purpose. Can we delete it?

  • Reported: PDME 1.3 — Fri, 19 Jan 2001 05:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    Agreed. Transactionable is no longer useful

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

ObjectChangeNotification models the "is"

  • Key: PDME14-16
  • Legacy Issue Number: 4147
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Specification: PDM Enablers v1.3 clause 2.10.3.19
    Source: Ted Briggs, Intergraph (SC4 AP227 project) via Ed Barkmeyer
    Problem: ObjectChangeNotification models the "is" part of the was/is relationship from ECN to Changeable, that is, it identifies
    the "new" version of the Changeable Item(s). But the text doesn't say that. The text of ObjectChange, which models the same
    relationship from ECO to Changeable, should also appear here.

  • Reported: PDME 1.3 — Thu, 11 Jan 2001 05:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    accepted. This is editorial clarification.

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

allow Documentable to point to a DocumentRevision or a DocumentMaster.

  • Key: PDME14-10
  • Legacy Issue Number: 4028
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    This seems to be primarily a ChangeManagement issue. The problem is tracking
    the relationship between an ECR and a requirements document. In some cases, it
    may be determined that a given change requirement is not quite right for all
    product (instances) in a line, so the scope of the first ECR is reduced, the
    requirement spec is "revised" and a second ECR is created with the revised
    spec. That is, there are two active ECRs with different versions of the "same"
    requirements document. (And the PDM Enablers should not require the company's
    business process to make that a new DocumentMaster!)

  • Reported: PDME 1.3 — Wed, 8 Nov 2000 05:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    see below

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

move Qualifiable up to EngChangeItem.

  • Key: PDME14-9
  • Legacy Issue Number: 4026
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    At the moment, ECO is Qualifiable, but EngChangeItem (the supertype) is not.
    Since shipbuilding does most change management by "serial number effectivity",
    i.e. Hull
    number or "functional unit HSC", they want to qualify Issues and ECRs as well.

  • Reported: PDME 1.3 — Wed, 8 Nov 2000 05:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    Accepted: Make EngChangeItem Qualifiable.

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

Provide an ID when creating an object

  • Key: PDME14-18
  • Legacy Issue Number: 4163
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    For transactional integrity and atomicity of PDM operations, the client needs to be able to provide an ID when creating a PDM
    Enablers Identifiable object. As it stands, the creation of the object and the assignment of its ID is done in a minimum of two
    operations, leaving the object exposed to an invalid (unidentified) state if there is failure between the two or more
    operations.

  • Reported: PDME 1.3 — Fri, 19 Jan 2001 05:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    see below

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

"interface repository name" is an undefined term.

  • Key: PDME14-13
  • Legacy Issue Number: 4130
  • Status: closed  
  • Source: NIST ( Mr. David Flater)
  • Summary:

    Edit directions against formal/2000-11-11:

    In Section 4.3.1, replace the text "interface repository name" with
    "interface repository RepositoryId." (Though "interface repository
    RepositoryId" is redundant, this harmonizes the text with RepositoryId
    references in Sections 3.3.5 and 3.3.6.)

  • Reported: PDME 1.3 — Wed, 27 Dec 2000 05:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    accepted

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

missing attribute in the IDL

  • Key: PDME14-12
  • Legacy Issue Number: 4129
  • Status: closed  
  • Source: Eigner + Partner AG ( Andreas Fester)
  • Summary:

    The UML diagram for the PdmProductStructureDefinition module shows an attribute make_buy for interface PartDataIteration, which also occurs in the detailed description of the interface. However, the attribute is missing in the IDL at the end of the chapter and in document dtc/2000-06-03 which contains the compilable IDL files.

  • Reported: PDME 1.3 — Thu, 21 Dec 2000 05:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    see below

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

Should all PDM Enablers IDL files begin with #pragma prefix "omg.org"

  • Key: PDME14-19
  • Legacy Issue Number: 4185
  • Status: closed  
  • Source: NIST ( Mr. David Flater)
  • Summary:

    Should all PDM Enablers IDL files begin with #pragma prefix "omg.org",
    or not?

  • Reported: PDME 1.3 — Wed, 24 Jan 2001 05:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    Yes. Modify the formal IDL files to include the #pragma.

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

Interactions to be specified

  • Key: PDME14-11
  • Legacy Issue Number: 4082
  • Status: closed  
  • Source: NIST ( Mr. David Flater)
  • Summary:

    The expected interactions between a component supporting PDM Enablers
    and a component supporting Workflow should be completely specified
    using sequence diagrams.

    Three feasible scenarios are identified but not specified in the
    Testability White Paper, test/2000-10-01.

  • Reported: PDME 1.3 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — PDME 1.4
  • Disposition Summary:

    This is further guidance for the revised text for Issue 3087.

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

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

How does a PDM Enabler server expect the format of wild cards?

  • Key: PDME-122
  • Legacy Issue Number: 1571
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1.10.2.4 Query Service. How does a PDM Enabler server expect the format of wild cards? (Review CORBA Query Service)

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    By using a very general model and by using predicates to deal with queries, the Query Service is de

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

Default for all systems needed

  • Key: PDME-121
  • Legacy Issue Number: 1570
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1.10.2.4 Query Service. At least one default that all systems can use to perform query or search is requested/needed.

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    It"s believed this issue is referring to a default Identification Context. See 1565 for resolution

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

Provide Data Dictionary

  • Key: PDME-106
  • Legacy Issue Number: 1549
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Provide Data Dictionary for PDM Enabler Objects/Attributes

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    The PDM Enablers is an interface specification and provides a standard mechanism to access PDM data

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

Engineering change document needed

  • Key: PDME-105
  • Legacy Issue Number: 1547
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. PDM Enablers shall support the need for a relationship between an Engineering Change and a Document describing the Engineering Change. In many Boeing systems today, the Engineering Change is written in the form of a document (this may be a hardcopy of a document or an image of a document). For future processes, the Document Object may still provide for electronic Engineering Change Forms.

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Resolved by Issue 1744

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

How do PDM Enablesr identify specific part not knowing specific context

  • Key: PDME-116
  • Legacy Issue Number: 1565
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2.2.3.5 IdentificationContext. How do PDM Enablers identify a specific part without knowing a specific context?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    The client must specify the id context as every id applies to a particular context, even if the use

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

specific queries

  • Key: PDME-115
  • Legacy Issue Number: 1564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1.10.2.4 Query Service. How do PDM Enablers provide a list of parts which meet a specific query, not knowing the context?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    The PDM Enablers define that the Query Service, defined in Chapter 11 of the CORBA COS services, sh

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

Modularity

  • Key: PDME-108
  • Legacy Issue Number: 1551
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Encourage modularity. Request PDM Enablers move in the direction of Modular Functions as the Maturity Model is developed. Convenience Function = Function

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Issue asks for no specific change

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

Need capability to return list Generalized Find (Query) capabilities

  • Key: PDME-107
  • Legacy Issue Number: 1550
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1.10.2.4 Query Service. Find operation only returns one object, cannot return a list. Need capability to return list. Generalized Find (Query) capabilities.

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Based on clarification from the submitter, it was determined that the Find in question is actually

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

DesignMakeFrom relationship, and DMFR Substitute

  • Key: PDME-110
  • Legacy Issue Number: 1557
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How do PDM Enablers accommodate Design MakeFrom Relationship (DMFR), and DMFR Substitute?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Accepted: Add MakeFromUsage relationship with quantity attribute inheriting from Usage Relationship

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

How should PDM relate to Workflow?

  • Key: PDME-109
  • Legacy Issue Number: 1553
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How should PDM relate to Workflow?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Resolved in Issue 2248

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

Are contexts meant to be the same across PDM Systems?

  • Key: PDME-118
  • Legacy Issue Number: 1567
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Are contexts meant to be the same across PDM Systems?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Contexts are expected to have similar semantics regardless of which PDM system is being used, howev

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

Can client be written to retrieve a part from multiple PDM systems?

  • Key: PDME-117
  • Legacy Issue Number: 1566
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Can a client be written to retrieve a part from multiple PDM systems

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Yes. A single client can be coded to obtain IdentificationContextFactory objects from separate PDM

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

Structured Documentation Capability provided?

  • Key: PDME-114
  • Legacy Issue Number: 1563
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Do PDM Enablers provide Structured Documentation Capability (e.g. Worldview, Document references chapters or paragraphs

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    The PDM Enabler provides basic document function such as create, delete and also simple structures

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

PDM_Image and PDM_Markup

  • Key: PDME-113
  • Legacy Issue Number: 1561
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How do we handle PDM_Image and PDM_Markup in PDMEnablers?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Out of scope extension which are not modeled by the current specification. However these may be han

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

How are argument formats for a query to be specified?

  • Key: PDME-120
  • Legacy Issue Number: 1569
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1.10.2.4 Query Service. How are argument formats for a query to be specified?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Defer to PDM implementers. This is an implementation specific question for the systems that impleme

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

How are defaults to be specified?

  • Key: PDME-119
  • Legacy Issue Number: 1568
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1.10.2.4 Query Service ??. How are defaults to be specified? With capital "D", ("Default"); With lower case "d" ("default"); Other?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Not sure if the question is understood, but the PDM Enablers does not define or describe the use of

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

How are models accommodated in PDM Enablers?

  • Key: PDME-112
  • Legacy Issue Number: 1559
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How are Models accommodated in PDM Enablers (Treated as Document to Part Relationship)?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Same as Issue 1554

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

How do PDM Enablers accommodate Alternate/Substitute Part ranking?

  • Key: PDME-111
  • Legacy Issue Number: 1558
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How do PDM Enablers accommodate Alternate/Substitute Part Ranking?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    The PDM Enablers place no requirements on ranking alternate or subsitute parts. If an alternate or

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

Make certain ConfigurationManagement interfaces Documentable

  • Key: PDME-130
  • Legacy Issue Number: 2439
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Problem: The following ConfigurationManagement interfaces inherit
    from Manageable, but do not support attached Document descriptions:
    ProductClass, SpecificationCategory, Specification, ProductComponent,
    ProductFunction. The descriptive string may be insufficient to
    document these properly, and may be subject to controlled revision.
    Therefore, these interfaces should be Documentable. The simplest
    solution is to change the inheritance from Manageable to ManagedEntity.

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

Subprocesses in section 1.12.7 and 1.12.9, that have been addressed by 2.9

  • Key: PDME-129
  • Legacy Issue Number: 2246
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: "Section 1.12.7 and Section 1.12.9 should be modified to clarify that the following sub-processes are addressed by section 2.9.3.17:
    Coordinate Design Change: Notify required team members
    Coordinate Design Change: Notify design change across all products
    Implement Product Changes: Alert Change"

  • Reported: PDME 1.0b1 — Mon, 7 Dec 1998 05:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Notify required team members

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

PDM Enablers file locking behavior

  • Key: PDME-131
  • Legacy Issue Number: 2485
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The PDM Enablers convenience document mfg/98-02-02, section 2.6.1,
    "PdmDocumentManagement Overview," explains checkin/checkout as follows:

    To perform a checkout, the client would first lock the file using the
    lock() operation. The client then transfers the file"s contents from
    the PDM server to it"s file system. To perform a checkin, the client
    creates a new DocumentIteration. It then creates a new File,
    associates it with the DocumentIteration, transfers the contents of the
    file from the client to the PDM server. Lastly, it unlocks the file.

    If every checkin creates a new DocumentIteration, then it follows that I
    would never actually change a File once it has been uploaded, because that
    would be an untracked change, and untracked changes are always bad and
    evil. So I don"t know why I"d ever need to lock a File.

  • Reported: PDME 1.0b1 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    No Data Available

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

PersonOrganization Issue

  • Key: PDME-124
  • Legacy Issue Number: 1576
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2.1.3.7 PersonOrganization. The IDL says that the PersonOrganization relationship has anattribute called "role". The picture of the IDL shows that there are noattributes in this relationship. The other relationship in this module(ProgramOwner) does not have any attributes. Also there is no correction toeither of these interfaces in the errata. Should I believe the IDL pictureor the text?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    Duplicate of OMG issue 1575

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

PersonOrganization relastionship -- IDL problem

  • Key: PDME-123
  • Legacy Issue Number: 1575
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2.1.3.7 PersonOrganization. The IDL says that the PersonOrganization relationship has anattribute called "role". The picture of the IDL shows that there are noattributes in this relationship. The other relationship in this module(ProgramOwner) does not have any attributes. Also there is no correction toeither of these interfaces in the errata. Should I believe the IDL pictureor the text?

  • Reported: PDME 1.0b1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    The IDL for PersonOrganization is correct and the "role" attribute should be included in the UML.

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

1.14.2.2.1 management of STEP Data

  • Key: PDME-126
  • Legacy Issue Number: 1919
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    ISSUE #19 REF: 1.14.2.2.1 Management of STEP Data

    STEP-compliant data can be managed by the PDM system in the same fashion as proprietary files. The STEP files provide standardized domain-specific semantics (having removed the closed, proprietary nature) that provide the potential for a broad range of tools to understand the file.

    This could be an improvement over the neutral image strategies currently in use.

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    1.14.2.2.1 Management of STEP Data

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

ISSUE #17 REF: 1.14.2.1.5 Versioning

  • Key: PDME-125
  • Legacy Issue Number: 1917
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A formal definition of version and release is needed here and elsewhere within this document. The terms version and revision seem to be used interchangably in different parts of the document.

  • Reported: PDME 1.0b1 — Mon, 31 Aug 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    In Section 1.14.2.1.5 the term "Version" and "Versioning", and "Release" are used in their general,

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

There is no way to find or navigate to a PdmDocumentManagement::Vault inte

  • Key: PDME-128
  • Legacy Issue Number: 2159
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    There is no way to find or navigate to a PdmDocumentManagement::Vault interface.

    The Vault interface does not inherit the CosGraphs::Node interface, which would allow clients to navigate to the Vault containing a SecuredFile.

    In addition, there is no interface to allow one to find a Vault given its id. A find operation could be added to the SecuredFileFactory interface to provide this capability. Since a Vault is an administrative object of the PDM system rather than an item managed by the PDM system, it is probably not appropriate to make it a ManagedEntity or Identifiable interface.

  • Reported: PDME 1.0b1 — Mon, 2 Nov 1998 05:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:

    :Vault interface.

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

There are some bugs in the AssemblyComponentUsage

  • Key: PDME-127
  • Legacy Issue Number: 2112
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are some bugs in the AssemblyComponentUsage specification and the IDL
    in 2.7.4 differs from the description in 2.7.3.2:

    2.7.3.2 AssemblyComponentUsage
    2.7.4 PdmProductStructureDefinition IDLP

  • Reported: PDME 1.0b1 — Wed, 21 Oct 1998 04:00 GMT
  • Disposition: Resolved — PDME 1.0b2
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT