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.

Duplicate from issue 3760, clos eissue

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.

Duplicate of 3154. Closed

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.

No Data Available

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.

see below

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-

see below

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.

Change text

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"

Correct UML.

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!)

see below

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.

resolved in 1.2 RTF

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.

resolved by 1.2 RTF

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.

see below

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

see above

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.

accepted as proposed

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?

see above

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?

Agreed. Transactionable is no longer useful

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.

accepted. This is editorial clarification.

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!)

see below

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.

Accepted: Make EngChangeItem Qualifiable.

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.

see below

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

accepted

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.

see below

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

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

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.

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

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.

resolved and closed. Read spec to view UML diagrams

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.

resolved/accepted

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.

see below

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.

This issue was referred to RFP, and is addressed in the PDM Enablers v2 revised proposal.

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.

accepted in principle

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.

see above

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.

See the resolution to issue 3309

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.

accepted and resolved

Description:
ViewQualification is an abstract interface. Why is a
"ViewQualificationFactory"
defined?

accepted in principle

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

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

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

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

Summary: Provide Data Dictionary for PDM Enabler Objects/Attributes

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

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.

Resolved by Issue 1744

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

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

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?

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

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

Issue asks for no specific change

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.

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

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

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

Summary: How should PDM relate to Workflow?

Resolved in Issue 2248

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

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

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

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

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

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

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

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

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

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

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

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

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

Same as Issue 1554

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

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

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

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"

Notify required team members

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.

No Data Available

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?

Duplicate of OMG issue 1575

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?

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

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.

1.14.2.2.1 Management of STEP Data

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.

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

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.

:Vault interface.

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

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