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 1547: Engineering change document needed
Issue 1548: IdentificationContext appears not to be value added
Issue 1549: Provide Data Dictionary
Issue 1550: Need capability to return list Generalized Find (Query) capabilities
Issue 1551: Modularity
Issue 1552: Identify cases where interoperability between PDM systems is of use
Issue 1553: How should PDM relate to Workflow?
Issue 1554: Use of PDM Enablers without modifying them
Issue 1556: How can we extend ICOM
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 1560: Note Objects currently not addressed
Issue 1561: PDM_Image and PDM_Markup
Issue 1562: Document and/or Drawing Sheet Information
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 1572: Use of PDM Enablers.
Issue 1573: What Security Systems are used with the PDM Enablers?
Issue 1574:
Issue 1575: PersonOrganization relastionship -- IDL problem
Issue 1576: PersonOrganization Issue
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 1917: ISSUE #17 REF: 1.14.2.1.5 Versioning
Issue 1918: ISSUE #18 REF: 1.14.2.1.6 Assembly Model
Issue 1919: 1.14.2.2.1 management of STEP Data
Issue 1920: REF: 1.15 Other Information
Issue 1922: Vault attributes shown as being read - write
Issue 2101: Problem creating certain objects
Issue 2112: There are some bugs in the AssemblyComponentUsage
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 2159: There is no way to find or navigate to a PdmDocumentManagement::Vault inte
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 2246: Subprocesses in section 1.12.7 and 1.12.9, that have been addressed by 2.9
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 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 3086: Attributes
Issue 3087: Workflow
Issue 3088: Factory Finder Conventions
Issue 3089: IdentificationContext Conventions
Issue 3090: Convention for Creating Items
Issue 3154: PdmContext is insufficient as a TraversalCriteria
Issue 3155: PdmContext is insufficient as a TraversalCriteria
Issue 3301: Vault object references
Issue 3309: Factories for non-abstract subtypes of Qualification
Issue 3310: Factories to non-abstract subtypes of Effectivity
Issue 3311: ConfigurationItem
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 4027: allow "document type" to be the IdContext "kind"
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 4131: "interface name" is ambiguous
Issue 4145: make_buy missing in IDL
Issue 4146: was/is relationships to The EngChangeAffectedData relationship
Issue 4147: ObjectChangeNotification models the "is"
Issue 4148: PDM RTF issue: "successor"
Issue 4161: IdentificationContext Considered Harmful
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 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: 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: 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: 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: 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: How should PDM relate to Workflow?

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: 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: 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 PDM_Image and PDM_Markup in PDMEnablers?

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

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

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.

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. 

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

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.

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

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.

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

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

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.

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

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?

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.