Product Data Management Enablers Avatar
  1. OMG Specification

Product Data Management Enablers — Open Issues

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

Issues Descriptions

Behavior of Lockable operations is not defined

  • Key: PDME-100
  • Legacy Issue Number: 4222
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. 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

IdentificationContext Considered Harmful

  • Key: PDME-99
  • Legacy Issue Number: 4161
  • Status: open  
  • Source: NIST ( Mr. 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 ( Mr. Edward J. 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 ( Mr. 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

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

  • Key: PDME-96
  • Legacy Issue Number: 4027
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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