Product Data Management Enablers Avatar
  1. OMG Specification

Product Data Management Enablers — Closed Issues

  • Acronym: PDME
  • Issues Count: 19
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
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
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

Issues Descriptions

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

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