Issues for Product Data Management (PDM) RTF 1.4 discussion list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1547: Engineering change document needed
Issue 1549: Provide Data Dictionary
Issue 1550: Need capability to return list Generalized Find (Query) capabilities
Issue 1551: Modularity
Issue 1553: How should PDM relate to Workflow?
Issue 1557: DesignMakeFrom relationship, and DMFR Substitute
Issue 1558: How do PDM Enablers accommodate Alternate/Substitute Part ranking?
Issue 1559: How are models accommodated in PDM Enablers?
Issue 1561: PDM_Image and PDM_Markup
Issue 1563: Structured Documentation Capability provided?
Issue 1564: specific queries
Issue 1565: How do PDM Enablesr identify specific part not knowing specific context
Issue 1566: Can client be written to retrieve a part from multiple PDM systems?
Issue 1567: Are contexts meant to be the same across PDM Systems?
Issue 1568: How are defaults to be specified?
Issue 1569: How are argument formats for a query to be specified?
Issue 1570: Default for all systems needed
Issue 1571: How does a PDM Enabler server expect the format of wild cards?
Issue 1575: PersonOrganization relastionship -- IDL problem
Issue 1576: PersonOrganization Issue
Issue 1917: ISSUE #17 REF: 1.14.2.1.5 Versioning
Issue 1919: 1.14.2.2.1 management of STEP Data
Issue 2112: There are some bugs in the AssemblyComponentUsage
Issue 2159: There is no way to find or navigate to a PdmDocumentManagement::Vault inte
Issue 2246: Subprocesses in section 1.12.7 and 1.12.9, that have been addressed by 2.9
Issue 2439: Make certain ConfigurationManagement interfaces Documentable
Issue 2485: PDM Enablers file locking behavior
Issue 2622: PDM Enablers - cannot determine client type for file transfer
Issue 2874: PDM RTF Issue - The Identifiable interface should raise InvalidProperties
Issue 3084: Session Management
Issue 3085: Authentication
Issue 3087: Workflow
Issue 3088: Factory Finder Conventions
Issue 3089: IdentificationContext Conventions
Issue 3154: PdmContext is insufficient as a TraversalCriteria
Issue 3155: PdmContext is insufficient as a TraversalCriteria
Issue 3309: Factories for non-abstract subtypes of Qualification
Issue 3310: Factories to non-abstract subtypes of Effectivity
Issue 3312: ViewQualification is abstract
Issue 3755: PdmFoundation Model (page 2-26)
Issue 3756: Some wording - the last paragraph on page 2-34 is wrong
Issue 3757: PdmFramework Entity Model (page 2-51)
Issue 3758: PdmViews Model (page 2-79)
Issue 3759: PdmDocumentManagement (page 2-93)
Issue 3760: PdmChangeManagement (page 2-150)
Issue 3761: PdmChangeManagement (page 2-150)
Issue 3804: addition of two exceptions to CosGraphs::Node::add_role().
Issue 3992: PdmFoundation.idl version 1.3, dtc/00-10-01
Issue 4026: move Qualifiable up to EngChangeItem.
Issue 4028: allow Documentable to point to a DocumentRevision or a DocumentMaster.
Issue 4082: Interactions to be specified
Issue 4129: missing attribute in the IDL
Issue 4130: "interface repository name" is an undefined term.
Issue 4145: make_buy missing in IDL
Issue 4146: was/is relationships to The EngChangeAffectedData relationship
Issue 4147: ObjectChangeNotification models the "is"
Issue 4162: Is Transactionable still needed?
Issue 4163: Provide an ID when creating an object
Issue 4185: Should all PDM Enablers IDL files begin with #pragma prefix "omg.org"

Issue 1547: Engineering change document needed (pdm-rtf)

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.

Summary: Provide Data Dictionary for PDM Enabler Objects/Attributes

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.

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

Summary: How should PDM relate to Workflow?

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

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

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

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

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

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?

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

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

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

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

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

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

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

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?

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?

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.

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.

 This recommended addition is an opinion that adds nothing to the purpose of the section.

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

 IDL in 2.7.3.2 will be corrected; IDL in 2.7.4 is correct (although misformatted).

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.
 

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"
 
 

 Section 1.12.7 and Section  1.12.9 should be modified to clarify that the following sub-processes ar

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

After initial investigation, the RTF has found that an adequate description of locking, check in, and check out requires additional analysis and more time. Resolution:

Locking has nothing to do with Files.  The diagrams in 7.3.14 incorrectly include lock and unlock operations.  The text and diagrams of 7.3.14 should be restricted to the expected sequences for data transfer.

There are two separate issues that might be addressed.  
What exactly does Lock do on various things? After initial investigation, the RTF has found that an adequate description of locking, check in, and check out requires additional analysis and more time.  

Give an example of checkin and checkout?  This is very business process dependent, and should be only in a tutorial document.  No version can be normative, and we don't want to give a false impression.

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.
 

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.
 

Add InvalidProperties exceptions as suggested.
Revised Text:
In the IDL in section 2.2.3.4 Identifiable, and in section 2.2.4 PdmFoundation IDL, add the InvalidProperties exception to the raises clause of the change_id operation.

In the IDL in section 2.2.3.5 IdenticationContext, and in section 2.2.4 PdmFoundation IDL, add the InvalidProperties exception to the raises clause of the generate_id operation.

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.

There are at least two possible approaches:
1)	register a different object, with a login operation, say PdmLogin::login(un,pw), which returns a PdmSystem for that user's session.
2)	(preferred) Register the PdmSystem object with the name service, and require separate authentication compatible with the CORBA Security Service.  This solution is interrelated with Issue 3085 Authentication.

The resolution of this issue is deferred until there is a resolution to Issue 3085.

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.

A PDM Enablers implementation may be built or used with a secure ORB supporting the CORBA Security Services specification.  If so, the PDM system should use the security services to authenticate users and check credentials in order to enforce its access rules.

In the case in which a secure ORB is not in place, the PDM system implementation must provide its own interfaces and implementations to authenticate its users and enforce its access rules.  So that arbitrary PDM Enablers clients can expect a consistent interface to their services, it is recommended that such implementations provide and use interfaces that are consistent with the form of the Security Services interfaces, even if they provide no claim of security.

However, until a working test or prototype has been implemented and verified to work, it is premature to revise the formal specification.  The final resolution of this issue is deferred.
Resolution:
A PDM Enablers implementation may be built or used with a secure ORB supporting the Common Secure Interoperability Services v2 specification.  If so, the PDM system should use the security services to authenticate users and check credentials in order to enforce its access rules.  

In the case in which a secure ORB is not in place, the PDM system implementation must provide its own interfaces and implementations to authenticate its users and enforce its access rules.  

The use of PDM Enablers with Common Secure Interoperability Services v2 is addressed in the revised text.  However, the larger issue was referred to RFP, and is addressed in the PDM Enablers v2 revised proposal.

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.

PdmSystem will provide an operation to acquire its WfRequester, which may be itself, another object, or nil (NotImplemented).

See also issue 4082, which requires sequence diagrams for Workflow/PDM interactions.

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.

The form and value for the name naming convention (from Table 6-1 of omg/formal/98-07-05) is <id=FactoryName, kind="factory interface">, where the FactoryName is the interface repository RepositoryID.
A request for an unknown factory will throw exception NoFactory

It was discussed that factories could be registered individually, but it was decided that this is undesirable, since registering the factories with the NameService will violate the single point of access principle for the PdmSystem interface.

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.

IdentificationContexts are differentiated in two separate ways, and names should contain at least two pieces of information.  These are:
1) The name of IdentificationContext specific to the Company/Organisation/Department/Project/etc. These should allow PDM users to define their own IdentificationContexts which are specific and meaningful to their business.
2) The IDL type of the objects scoped by the IdentificationContext.  Whenever the client makes a request of the server for an object reference (specified by an identifier and an IdentificationContext) the client will expect the object reference to be of certain type. 

This solution uses the CosNaming::NameComponent type for representing IdentificationContext names., rather than a string as is used in PDM Enablers V1.2.  This allows both types of information to be used together.

Additional mechanisms are provided to make IdentificationContext names available to clients at run time.   The IdentificationContextFactory interface is extended to support additional operations to return the IdentificationContext objects known to the system

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.

The proposal is essentially adopted.  The following UML diagram (not intended to be included in the specification in this form) shows the change and how the interfaces use and depend on the CosGraphs interfaces.
 

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.

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.

The factories of LifeCycleQualification, LocationQualification, DisciplineQualification, DatedEffectivity, LotEffectivity, SerialNumberEffectivity should be able to populate all attributes of the interface itself and of all inherited interfaces. 

This statement is valid for two more interfaces derived from Qualification: ViewQualification and CompoundQualification.

Therefore, the corresponding factories should use a generic PropertySet attribute:

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.

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

See Resolution to Issue 3309.
ViewQualification denotes a particular view not to be qualified by lifecycle, location nor discipline. The statement "abstract type" is misleading. A factory to construct a ViewQualification in its own right is justified.

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"

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.

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

Resolution:
Correct the UML spelling to match the IDL spelling.  (The spelling "updateable" is Oxford; the spelling "updatable" is Webster.)

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

Resolution:

Add name:string in UML diagram for ViewQualification.
Delete "attribute string description;" from published IDL. 

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.

Comment is correct.  The published IDL is right; the IDL snippet on 2-97 is wrong.
Also SecuredFile::size is readonly.

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.

Resolution:
Via inheritance from ManagedEntity and thus from Manageable, EngChangeItem inherits short_description and long_description attributes (ref. issue 2150).  So the (extra) "description" attribute should be deleted from the IDL.

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.

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?

Resolution:
1. CosRelationships already provides for throwing exceptions if add_role is invoked to add a Role to a Node that already has a Role of that type, or if add_role is invoked to add an inadmissible Role to a Node.  Any required clarification of that text, e.g. for subtypes of Roles, will be forwarded to the Relationships RTF as a CosRelationships issue.  

2.  The only PDM Enablers Roles that might be affected by restrictions on Role subtypes are those of PdmTypedRelationship.  It is the only non-abstract Relationship that has subtypes.  But, as defined, it causes PdmReferencesRole and PdmReferencedByRole to be directly instantiated.  That is not the intent, and may cause problems with the unique instantiation rule (see below).  This will be raised as a separate issue.

3. CosRelationships provides that all Roles shall be uniquely assumed by a given Node.  It need not be repeated in the PDM Enablers and there is no good place to put such wording.  Note 3 is interesting, but it is at best an issue for CosRelationships (and Party Management Facility).  PDM Enablers Roles have no attributes or operations and can thus be unique for a Node without loss of semantics.

4.  The PDM Enablers relationship definitions shall not be interpreted as specifying the complete set of Role types that may be assumed by a PDM Enablers interface that inherits from Node.  For example, some PDM Enablers objects may also accept Workflow or DocumentRepository Roles.  

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.

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. 

*Recommendation: Make ECI Qualifiable, instead of just ECO.

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

Resolution:
There are many reasons for a Documentation relationship to point to a specific revision of a controlled document, such as technical requirements or standard handling and processing procedures, because the effectivities of the Document and the Documentable may not be synchronized.

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.

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.

Resolution:
The IDL is right.  The UML is incorrect.  make_buy as a STEP-defined attribute has explicit values with explicit interpretations, and that should be part of the STEP Profile (see issue 3086).  Whether, how and where the make/buy decision is represented in terms of PDM attributes and values is more generally a matter for company business processes and the company-specific schema.  The make_buy attribute should be removed from the IDL and the UML.

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

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

Resolution:
Not accepted.  make_buy is one or more attributes that may belong to PartMaster, PartRevision or PartDocument attribute sets, as well as PartData.

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.

Resolution: 

Add "role" attribute, expand definition of "disposition" to mean "status", as described in the summary. 
Change name of relationship as requested.

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.

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?

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.

Resolution:
As written, this is rejected.  There is no problem with transactional integrity.  The PDM Enablers require atomicity of the create operations, which implies that the underlying PDM implementation must do whatever is necessary to create a complete and referenceable object.  And accordingly, the implementation will require such attributes on a create operation as are needed to accomplish that.  In general, that means that some set of the attributes provided on a create operation for an Identifiable object will be used to create an identifier for the object in some IdentificationContext.  And in many cases, the local PDM administrator will have determined which attributes are used to create the identifier and how.  In the simplest case, the question is "which attribute is the principal identifier?"

In fact, if the client knows the IdentificationContext in which the "assignment of its ID [via a bind() operation] is done", then the client should be able to follow the create() operation with a get_id() on the resulting object and verify that the expected ID has been assigned.  And conversely, following the create() with a bind() operation on that IdentificationContext might be expected to throw CardinalityExceeded.

More generally, this issue assumes, but the PDM Enablers does not say, that the principal means of identification of (internal) PDM objects is somehow exposed through the Identification relationship.  In fact, all the PDM Enablers says is that some external identification means is exposed.  And the UML model does not even require that an Identifiable object have at least one Identification relationship, ever.  The object has an IOR which is mapped to its internal referencer.

The RTF agrees that the expected functionality of create operations and identification should be discussed in section 3.3.7, which generally discusses the behavior of Identification relationships.

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