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 1546: PDM Enablers shall support use of a Note Object
Issue 1548: IdentificationContext appears not to be value added
Issue 1552: Identify cases where interoperability between PDM systems is of use
Issue 1554: Use of PDM Enablers without modifying them
Issue 1556: How can we extend ICOM
Issue 1560: Note Objects currently not addressed
Issue 1562: Document and/or Drawing Sheet Information
Issue 1572: Use of PDM Enablers.
Issue 1573: What Security Systems are used with the PDM Enablers?
Issue 1574:
Issue 1643: IDL consistency Issue for PDM
Issue 1708: PDM Enablers issue - PartDataFactory attributes
Issue 1721: Illegal usage of keyword "context"
Issue 1742: Change cardinality of ComponentHierarchy-Relationship
Issue 1743: Add relationship from document master directly to vault
Issue 1744: Add relationships from most main objects to documents
Issue 1745: Configuration module: ProductRootToComponent - Relationship
Issue 1769: PDM Enablers IDL uses different include file names than CORBA Services IDL
Issue 1800: Duplicate Exceptions
Issue 1801: No City in PdmResponsibility
Issue 1895: Issue: Alignment of OMG Person/Party models
Issue 1901: Editorial changes to mfg/98-02-02
Issue 1902: Engineering Change Order
Issue 1903: Manufacturing Implementation
Issue 1904: Document management
Issue 1905: Product Structure definition
Issue 1906: Configuration Management
Issue 1907: Test, maintenance, and diagnostic information
Issue 1908: How does SWAP apply?
Issue 1909: ISSUE #9 REF: 1.11.3 Workflow , 1.14.4 Workflow Management Coalition (WfMC
Issue 1910: Develop Product Definition
Issue 1911: Develop Product Design
Issue 1912: REF: 1.12.6 Develop Process Design and Procurement Agreements
Issue 1913: REF: 1.12.6 Develop Process Design and Procurement Agreements
Issue 1914: REF: 1.13.3 CAD
Issue 1915: REF 1.13.4 ERP: add following bullets
Issue 1916: Differences in Purpose
Issue 1918: ISSUE #18 REF: 1.14.2.1.6 Assembly Model
Issue 1920: REF: 1.15 Other Information
Issue 1922: Vault attributes shown as being read - write
Issue 2101: Problem creating certain objects
Issue 2123: 1.14.1 Relationship to RM-ODP?
Issue 2124: 2.10.2 Level of control for Part manufacturing information
Issue 2125:
Issue 2127:
Issue 2128:
Issue 2129:
Issue 2130:
Issue 2131:
Issue 2132:
Issue 2133:
Issue 2134:
Issue 2135:
Issue 2137:
Issue 2138:
Issue 2139:
Issue 2140:
Issue 2141:
Issue 2142:
Issue 2143:
Issue 2144:
Issue 2145:
Issue 2146:
Issue 2147:
Issue 2148:
Issue 2149:
Issue 2150:
Issue 2151:
Issue 2152: Process - Part relationship
Issue 2154: PDM Enablers section 2.10.3.12
Issue 2158: The create method on the ItemSolutionFactory interface
Issue 2164: The Part - Document relationship
Issue 2166: UML - IDL consistency of role names
Issue 2168: Property-sets for non-Attributable relationships
Issue 2232: 2.6.3.2 Relationship Propogation when using the factory methods.
Issue 2236: 2.3.3.9 How is this related to ItemRevision::create_next_revision?
Issue 2237: Part Description text indicates discrete mfg
Issue 2238: 2.7.1 Concerned that the product structure is at too low a level in the hi
Issue 2239: The names of the relationships are unintuitive, such as prc
Issue 2241: Missing Usage roles
Issue 2242: Missing UML inheritances for Usage
Issue 2243: Misplaced Usage inheritance from SecurityClassifiable
Issue 2244: 2.7.3.2 description of reference_designator attribute
Issue 2245: Lack of role defintion.
Issue 2247: 2.9.3.5 EngChangeOrder : Add an “effectivity” (or “do it by”) attribute to
Issue 2248: Clarify and expand the text that explains how or why ECIs yield ECRs.
Issue 2250: PdmDocumentManagement IDL is obsolete
Issue 2257: Part Description text indicates discrete mfg,
Issue 2359: Figure 1 in section "2.2.3.5.1" has two incorrect object names
Issue 2360: Figure needs updates
Issue 2438: Change name DocumentRevisionRelationship to PartDocumentRelationship
Issue 3086: Attributes
Issue 3090: Convention for Creating Items
Issue 3301: Vault object references
Issue 3311: ConfigurationItem
Issue 4027: allow "document type" to be the IdContext "kind"
Issue 4131: "interface name" is ambiguous
Issue 4148: PDM RTF issue: "successor"
Issue 4161: IdentificationContext Considered Harmful
Issue 4222: Behavior of Lockable operations is not defined
Issue 4223: Define the Substitute Usage model
Issue 4259: Exception declaration inconsistent
Issue 4260: description of the get_info() operation states
Issue 4565: PDM RTF issue: no generic "set session properties" operation

Issue 1546: PDM Enablers shall support use of a Note Object (pdm-rtf)

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

 received issue

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?
 
 

 received issue

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

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 handle Document and/or Drawing Sheet Information in PDMEnablers?
 
 Disposition:
 

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

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

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

 The property_set parameter is deleted from the operations that create PartData and PartStructure.

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

 Throughout the specification, Change the IDL interface name "Context" to "PdmContext".  Where the plural form "Contexts" is used, change to "PdmContexts".  Occurrences are as follows:

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

 Duplicate exceptions have been eliminated

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

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.
 
 

This issue is deferred, pending coordination between the task forces on Person and Organization models.

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: 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 #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 #4	REF: 1.9.4	Document Management
 
 How about viewer technology? Native and neutral images. Grouped files (i.e. 3d CAD models)?
 
 

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

 Although Bill of Information may be a more accurate name, Bill of Material is an industry accepted t

Summary: ISSUE #6	REF: 1.9.7	Configuration Management
 
 How are revision rules addressed?
 

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

 The specification in Section 1.9.8 only indicates how test data can be associated with product. Othe

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

 Here is  text for  addition to section 1.14.4.

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 #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 #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 #12	REF: 1.12.6	Develop Process Design and Procurement Agreements
 Develop Manufacturing Facility Plan 
 Is this within the scope of PDM ????
 

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

 Requested by RFP. Possible PDM Enablers use.

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

 Converting CAD files is not a PDM function and managing complex file structure is not supported by t

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

 Text Correction Supplied

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

 Although there is a capability to treat software as Files in the PDM system, this topic is not discu

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

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: 1.14.1  Should we at a later date define relationship to RM-ODP?
 
 

 received issue

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 .  
 

 received issue

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: 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: The create method on the ItemSolutionFactory interface should raise
 ITEM_CREATE_EXCEPTION
 

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: 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 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: 2.6.3.2 How does architecture address relationship propagation by the factory methods? “copy forward”
 

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

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
 

 received issue

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)
 

 closed issue

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

 closed issue

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

 received issue

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.
 
 

 received issue

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

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.
 
 

 received issue

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
 

 closed issue

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: Figure needs updates (related to Issue 9?)
 
 

 received issue

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

There is general consensus on the need to define an information model conformance compatible with STEP.  As part of the solution,  there may be a need for new IDL to determine what information model set is used or expected by the system.

The resolution of this issue is deferred.  A joint STEP-OMG harmonization task force is underway and is expected to make recommendations in this area. There is general consensus on the need to define an information model conformance compatible with STEP.  There may also be a need to support the Open Applications Group information models and those of other standards bodies and consortia.  As part of the solution,  it is agreed that the PDM Enablers should support standard "profiles" for naming Properties of many PDM Enablers interface types, and for naming types of Documents.  This feature was referred to RFP and will be addressed in the PDM Enablers v2.0 proposal.

To complete alignment with STEP exchange models, other IDL changes may also be needed.  A joint STEP-OMG harmonization task force is underway and is expected to make recommendations in this area. 

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?

It may be impractical to fully define required combinations of data and still be compatible with different customer requirements.  This issue may eventually be partially addressed in conjunction by the definition of specific information models, as discussed in issue 3086. It may be impractical to fully define required combinations of data and still be compatible with different customer requirements.  This issue may eventually be partially addressed in conjunction by the definition of specific information models, as discussed in issue 3086.

A mechanism for the client to determine the properties needed should be part of the Profiles facility requested in the V2 RFP.

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. 

It is agreed that a method for obtaining references to all of the vaults of a PDM system would be useful. 
It was suggested that the solution proposed in the Summary of this issue (i.e. to add get_vaults() operation to VaultFactory) is perhaps out of scope of the VaultFactory interface. The reasoning behind this suggestion was that Factories normally only support a create() operation - to create new objects. 

Although this is true in principle, it must also be noted that the VaultFactory interface is not a typical Factory, in that it does not support a create() operation at all. Instead it supports a find(in string vault_id) operation. Thus, the get_vaults() operation does fit in with the scope of VaultFactory, and would be a useful extension. 

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

The original intent was that a ConfigurationItem is a "role" of an ItemMaster or a ProductClass that is implicitly maintained in the underlying PDM and exposed only through this interface.  And in that view it should be an abstract class (which provides only relationships to Effectivity Qualifications and Contexts) that is explicitly inherited by ItemMaster and ProductClass.   But it is also provided as a stand-in for ProductClass for implementations that support PdmEffectivity but do not support the PdmConfigurationManagement module.  And in that case, one might want a factory for it, or one might want to expose ProductClass and its factory, e.g. as ItemClass, in PdmFramework.

Note that the ConfigurationDesignRelationship (ConfigurationItem to ItemMaster), which has a factory in v1.3, has a similar problem:  It is actual and needs a factory when PdmConfigurationManagement is not supported, but it is virtual (through other relationships) and should not have a factory when PdmConfigurationManagement is supported.

Because the PdmConfigurationManagement module is being replaced in PDM Enablers v2.0 and the relationship between ProductClass and ItemMaster is being addressed in that work, this issue is deferred to PDM Enablers v2.0.

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

*Recommendation: not clear.  This might work for DocumentMaster, but it creates
problems for DocumentRevision and DocumentIteration.  (There is a related
"profiles" issue for PDME v2.) This might work for DocumentMaster, but it creates problems for DocumentRevision and DocumentIteration.  This is best considered with the whole IdentificationContext issue (4161).

But "document type" does not exist as a defined attribute in PDM Enablers v1.3.  And there is a v2 proposal for adding an "item_type" attribute to ItemMaster, which would relate directly to this issue.  

This issue is deferred, pending the handling of "item type" in PDM Enablers v2.

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

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!

The behavior requested is supported by the existing model, but discussion of standard traversals in v2 may identify the need for an explicit successor relationship at a higher level.

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

none.  The RTF agreed that there is a problem, but could not agree on a solution to it.  

The problem stated in bullets 1 and 3 is more or less correct - there are two independent ideas here and they have been grouped and objectified, and the current text does not explain/require enough to allow interoperable clients to be constructed.  It is also true that this grouping complicates the definition of Bill of Materials queries and simplified traversal operations, features requested in the V2 RFP.

The proposed resolution is to remove the second idea - object type as a naming scope - because it is implementation-dependent.  And the RTF voted on a proposed text revision to accomplish that resolution, but that proposal did not have majority support.  

This idea was added to v1.3 in part to reflect the fact that type as a naming scope is a common feature of PDM systems.  An alternative proposal to further explain this aspect of the existing IDL was also voted on and failed.  Unfortunately, type as a naming scope is a basis for "queries" in many PDM systems as well, and at least one pilot project used this added feature for that purpose.  Because a query facility is a required feature of the V2 RFP, it is a concern of some of the RTF members, who are V2 submitters, that this "alternate query facility" should be removed rather than further "enhanced".

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.

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.  

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. 

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. 

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.