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.

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.

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.

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.

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.

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

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

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

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

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

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

Summary: Reference: PDM Enablers 2.7.3.2, 2.7.3.20

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

Summary: Reference: PDM Enablers 2.7.2

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

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

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

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

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

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

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

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

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

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

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

Summary: Reference: PDM Enablers 2.7.3.20

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

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

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

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

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

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

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

Summary: ISSUE #20 REF: 1.15 Other Information

Other materials are not provided as part of this proposal.

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

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

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

Summary: ISSUE #15 REF: 1.13.4 ERP

Add the following bullets:

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

Summary: ISSUE #14 REF: 1.13.3 CAD

Add the following bullet:

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

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

How does SWAP apply ?

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

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

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

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

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

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

ERP integration at this stage is crucial!

Summary: ISSUE #6 REF: 1.9.7 Configuration Management

How are revision rules addressed?

Summary: ISSUE #5 REF: 1.9.5 Product Structure Definition

BOI or BOM perspective?

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

Summary: ISSUE #4 REF: 1.9.4 Document Management

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

Summary: ISSUE #3 REF: 1.9.3 Manufacturing Implementation

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

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

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

Summary: ISSUE #16 REF: 1.14.2.1.1 Differences in Purpose

Modify bullets as follows:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Configuration Management Module
SpecificationCategoryComposition Relationship

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

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

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

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

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

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

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

Summary: ISSUE #2 REF: 1.9.2 Engineering Change Order

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

Summary: ISSUE #1 - Editorial changes

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

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

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

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

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."

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!

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?]

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.

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?

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.

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

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".

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

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

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

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

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

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

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

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

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

Disposition:

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

Disposition:

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

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

Disposition:

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

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

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

Disposition: