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

To comment on any of these issues, send email to pdm-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

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

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

Issue 1547: Engineering change document needed
Issue 1549: Provide Data Dictionary
Issue 1550: Need capability to return list Generalized Find (Query) capabilities
Issue 1551: Modularity
Issue 1553: How should PDM relate to Workflow?
Issue 1557: DesignMakeFrom relationship, and DMFR Substitute
Issue 1558: How do PDM Enablers accommodate Alternate/Substitute Part ranking?
Issue 1559: How are models accommodated in PDM Enablers?
Issue 1561: PDM_Image and PDM_Markup
Issue 1563: Structured Documentation Capability provided?
Issue 1564: specific queries
Issue 1565: How do PDM Enablesr identify specific part not knowing specific context
Issue 1566: Can client be written to retrieve a part from multiple PDM systems?
Issue 1567: Are contexts meant to be the same across PDM Systems?
Issue 1568: How are defaults to be specified?
Issue 1569: How are argument formats for a query to be specified?
Issue 1570: Default for all systems needed
Issue 1571: How does a PDM Enabler server expect the format of wild cards?
Issue 1575: PersonOrganization relastionship -- IDL problem
Issue 1576: PersonOrganization Issue
Issue 1917: ISSUE #17 REF: 1.14.2.1.5 Versioning
Issue 1919: 1.14.2.2.1 management of STEP Data
Issue 2112: There are some bugs in the AssemblyComponentUsage
Issue 2159: There is no way to find or navigate to a PdmDocumentManagement::Vault inte
Issue 2246: Subprocesses in section 1.12.7 and 1.12.9, that have been addressed by 2.9
Issue 2439: Make certain ConfigurationManagement interfaces Documentable
Issue 2622: PDM Enablers - cannot determine client type for file transfer
Issue 2874: PDM RTF Issue - The Identifiable interface should raise InvalidProperties
Issue 3088: Factory Finder Conventions
Issue 3089: IdentificationContext Conventions
Issue 3154: PdmContext is insufficient as a TraversalCriteria
Issue 3155: PdmContext is insufficient as a TraversalCriteria
Issue 3309: Factories for non-abstract subtypes of Qualification
Issue 3310: Factories to non-abstract subtypes of Effectivity
Issue 3312: ViewQualification is abstract

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

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: 
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.

Resolution: Resolved by Issue 1744
Revised Text:
Actions taken:
June 24, 1998: received issue
August 24, 1999: closed issue

Discussion: 




Issue 1549:  Provide Data Dictionary                                                                                                                                                                                (pdm-rtf)

Click here for this issue's archive.


Nature:  Revision

Severity: 

Summary: 
Summary: Provide Data Dictionary for PDM Enabler Objects/Attributes



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1550:  Need capability to return list Generalized Find (Query) capabilities                                                                                                                                   (pdm-rtf)

Click here for this issue's archive.


Nature:  Revision

Severity: 

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1551:  Modularity                                                                                                                                                                                             (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



Resolution:  Issue asks for no specific change

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1553:  How should PDM relate to Workflow?                                                                                                                                                                     (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

Summary: 
Summary: How should PDM relate to Workflow?



Resolution:  Resolved in Issue 2248

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1557:  DesignMakeFrom relationship, and DMFR Substitute                                                                                                                                                       (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



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

Revised Text:  1. In UML model 2.7.2 add new interface MakeFromUsage which inherits from Usage. The MakeFromUsage has one attribute quantity of type Measurement.


Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1558:  How do PDM Enablers accommodate Alternate/Substitute Part ranking?                                                                                                                                     (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1559:  How are models accommodated in PDM Enablers?                                                                                                                                                           (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



Resolution:  Same as Issue 1554

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1561:  PDM_Image and PDM_Markup                                                                                                                                                                               (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1563:  Structured Documentation Capability provided?                                                                                                                                                          (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1564:  specific queries                                                                                                                                                                                       (pdm-rtf)

Click here for this issue's archive.


Nature:  Clarification

Severity:  Minor

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1565:  How do PDM Enablesr identify  specific part not knowing specific context                                                                                                                               (pdm-rtf)

Click here for this issue's archive.


Nature:  Clarification

Severity:  Minor

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1566:  Can client be written to retrieve a part from multiple PDM systems?                                                                                                                                    (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1567:  Are contexts meant to be the same across PDM Systems?                                                                                                                                                  (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1568:  How are defaults to be specified?                                                                                                                                                                      (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity:  Minor

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1569:  How are argument formats for a query to be specified?                                                                                                                                                  (pdm-rtf)

Click here for this issue's archive.


Nature:  Clarification

Severity:  Minor

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1570:  Default for all systems needed                                                                                                                                                                         (pdm-rtf)

Click here for this issue's archive.


Nature:  Enhancement

Severity:  Minor

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1571:  How does a PDM Enabler server expect the format of wild cards?                                                                                                                                         (pdm-rtf)

Click here for this issue's archive.


Nature:  Clarification

Severity:  Minor

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



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

Revised Text: 

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1575:  PersonOrganization relastionship -- IDL problem                                                                                                                                                        (pdm-rtf)

Click here for this issue's archive.


Nature:  Revision

Severity:  Minor

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



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

Revised Text:  Update the UML in 2.1.2 so that the PersonOrganization object includes the attribute "role : string".

Actions taken:

June 24, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1576:  PersonOrganization Issue                                                                                                                                                                               (pdm-rtf)

Click here for this issue's archive.


Nature:  Revision

Severity:  Minor

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



Resolution:  Duplicate of OMG issue 1575

Revised Text: 

Actions taken:

June 24, 1998: received issue

September 20, 1999: closed issue


Discussion: 




Issue 1917:  ISSUE #17	REF: 1.14.2.1.5	Versioning                                                                                                                                                                   (pdm-rtf)

Click here for this issue's archive.


Nature:  Revision

Severity: 

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



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

Revised Text: 

Actions taken:

August 31, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 1919:  1.14.2.2.1 management of STEP Data                                                                                                                                                                     (pdm-rtf)

Click here for this issue's archive.


Nature:  Revision

Severity: 

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



Resolution:  1.14.2.2.1	Management of STEP Data


Revised Text: 

Actions taken:

August 31, 1998: received issue

August 24, 1999: closed issue


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




Issue 2112:  There are some bugs in the AssemblyComponentUsage                                                                                                                                                      (pdm-rtf)

Click here for this issue's archive.


Nature:  Revision

Severity:  Significant

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



Resolution: 


Revised Text: 

Actions taken:

October 21, 1998: received issue

August 24, 1999: closed issue


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




Issue 2159:  There is no way to find or navigate to a PdmDocumentManagement::Vault inte                                                                                                                             (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



Resolution: :Vault interface.


Revised Text: 

Actions taken:

November 2, 1998: received issue

August 24, 1999: closed issue


Discussion: 




Issue 2246:  Subprocesses in section 1.12.7 and 1.12.9, that have been addressed by 2.9                                                                                                                             (pdm-rtf)

Click here for this issue's archive.


Nature: 

Severity: 

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



Resolution:   Notify required team members

Revised Text:   Notify design change across all products

Actions taken:

December 7, 1998: received issue

August 24, 1999: closed issue


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




Issue 2439:  Make certain ConfigurationManagement interfaces Documentable                                                                                                                                           (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



Resolution: 


Revised Text: 

Actions taken:

February 4, 1999: received issue

August 24, 1999: closed issue


Discussion: 




Issue 2622:  PDM Enablers - cannot determine client type for file transfer                                                                                                                                          (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



Resolution: resolved by 1.2 RTF

Revised Text: PdmProductStructureDefinition::PartMaster::part_type and part_classification: it is unclear what to do if a part has multiple classes or just doesn't mesh with AP203. Recommend clarifying and generalizing the definitions to support AP210 and 214.
Resolution:
The STEP AP203-specific value restrictions are removed from the specification.  Values of these fields must be general enough to support a variety of information models, depending on the PDM system implementation and business rules.
Revised Text:
Replace the attribute descriptions in the table in 2.7.3.10 PartMaster with following:

part_type	Indicates the type of the part.  Meaning and valid values may be determined by the site's business rules or by reference to another information model standard, such as a STEP application protocol.

part_classification	Provides a way to classify the part.  Meaning and valid values may be determined by the site's business rules or by reference to another information model standard, such as a STEP application protocol.


Actions taken:

April 27, 1999: received issue

April 27, 1999: received issue

May 4, 2000: closed issue


Discussion: 




Issue 2874:  PDM RTF Issue - The Identifiable interface should raise InvalidProperties                                                                                                                              (pdm-rtf)

Click here for this issue's archive.


Nature:  Uncategorized Issue

Severity: 

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



Resolution: resolved in 1.2 RTF

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


Actions taken:

September 1, 1999: received issue

May 4, 2000: closed issue


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





Issue 3088: Factory Finder Conventions                                                                                                                                                                              (pdm-rtf)

Click here for this issue's archive.


Source: Hewlett-Packard (Mr. Duane Silkworth, nobody duane.silkworth@eds.com)

Nature: Uncategorized Issue

Severity: 

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



Resolution: accepted in principle

Revised Text: Replace paragraph 1 of 2.4.3.1 PdmSystem. by the following two paragraphs:

The PdmSystem represents the services of a single PDM system. As a LifeCycle
FactoryFinder, it provides a destination location for the life cycle services copy and move operations. Furthermore, it can find all the other factories that are provided by the PDM Enablers server via the find_factories operation. 

The find_factories operation takes a Name Service style composite name as a parameter to identify the factory. The composites of the name comprise an id and a kind field. Following the naming conventions from Table 6-1 of omg/formal/98-12-09, interoperable clients and servers shall use the interface repository name of the factory interface for the id field and the string "factory interface" for the kind field.   Furthermore, it is suggested that the PdmSystem support one factory of each type.


Actions taken:

November 29, 1999: received issue

October 10, 2000: close dissue, accepted


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





Issue 3089: IdentificationContext Conventions                                                                                                                                                                       (pdm-rtf)

Click here for this issue's archive.


Source: Hewlett-Packard (Mr. Duane Silkworth, nobody duane.silkworth@eds.com)

Nature: Uncategorized Issue

Severity: 

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



Resolution: resolved/accepted

Revised Text: Add the following after the first paragraph of Section 2.3.3.5 IdentificationContext:

Implementations may provide a separate IdentificationContext for each Identifiable type, or may provide one or more IdentificationContext objects that support multiple types of Identifiable object.

Each IdentificationContext is identified by a CosNaming::NameComponent, defined by CosNaming as:
Struct NameComponent {
    Istring id;
    Istring kind;
}

The id field represents the business-related name. If the implementation supports a default identification context or only one identification context for a kind, the default id is represented by the empty string, i.e. a string of length 0.

The kind field indicates the type of the Identifiable objects managed by the IdentificationContext.  If the IdentificationContext supports a single type of Identifiable Item, the kind field has the form of the interface repository RepositoryId for the InterfaceDef of the Identifiable object.  If the IdentificationContext supports more than one type of Identifiable item, then the kind field may contain the RepositoryId for the common supertype of the items, or the content of the kind field may be implementation dependent. 

Change the IDL in section 2.3.3.5 IdentificationContext and section 2.3.4 PdmFoundation IDL as follows:

Add the following to the beginning of the #include section:
#include <CosNaming.idl>

Add the following definitions immediately before the definition of the IdentificationContext interface:
typedef CosNaming::NameComponent  IdentificationContextName;
typedef sequence <IdentificationContextName> IdentificationContextNames;
typedef sequence <IdentificationContext> IdentificationContexts;

In the definition of IdentificationContext, change the definition of attribute id from
    attribute string id;
to
    attribute IdentificationContextName name;

Change the definition of interface IdentificationContextFactory to:
interface IdentificationContextFactory
{
    IdentificationContext create(
        in CosPropertyService::PropertySet property_set)
        raises(ITEM_CREATE_EXCEPTIONS);

    IdentificationContext find_id_context(
        in IdentificationContextName the_context_name)
        raises(NotFound, PDM_EXCEPTIONS); 
    
    IdentificationContexts find_all_id_contexts()
        raises (PDM_EXCEPTIONS);
   
    IdentificationContexts find_id_contexts( in string identifiableType )
        raises(NotFound, PDM_EXCEPTIONS);
}

Add the following as the last paragraph of section 2.3.3.5 IdentificationContext:

find_all_id_contexts
Returns all identification contexts supported by the implementation.

find_id_contexts
Returns all identification contexts that identify objects of a given type.  The identifiableType parameter is in the form of the interface repository RepositoryId for the InterfaceDef of the Identifiable object.


Actions taken:

November 29, 1999: received issue

October 10, 2000: closed sisue


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





Issue 3154: PdmContext is insufficient as a TraversalCriteria                                                                                                                                                       (pdm-rtf)

Click here for this issue's archive.


Source: Hewlett-Packard (Mr. Duane Silkworth, nobody duane.silkworth@eds.com)

Nature: Revision

Severity: Critical

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


Resolution: resolved and closed. Read spec to view UML diagrams

Revised Text: remove the class CosGraphs::TraversalCriteria and the inheritance arrow from PdmContext.

Add the following class to the class diagram:
 
Replace section 2.6.3.4 PdmContext with the following two sections.  This will cause the renumbering of subsequent sections:

2.6.3.4 PdmContext

A PdmContext is an object that is established by the client and used to specify that a particular constraint, condition, or purpose holds for operations or relationship navigation.

A PdmContext is used to help create a CosGraphs::TraversalCriteria, which can in turn be used to create CosGraphs::Traversal objects, which navigate relationships.  Only Qualifiable items with no Qualification or with at least one Qualification that matches the PdmContext are returned during the traversal.  Qualifiable items without a matching Qualification are ignored.

The PdmContext is an abstract object intended to be specialized to create different types of PdmContexts.

interface PdmContext {};

2.6.3.5 PdmTraversalCriteriaFactory

The PdmTraversalCriteriaFactory creates a CosGraphs::TraversalCriteria that can be used to navigate relationship graphs in a PDM Enablers system.

exception UnsupportedTraversalName
   {
      unsigned long error_code;
      string error_text;
   };

   interface PdmTraversalCriteriaFactory
   {
      CosGraphs::TraversalCriteria create_simple_traversal_criteria(
            in PdmContext pdm_context, in CORBA::InterfaceDef role_type);
      CosGraphs::TraversalCriteria create_named_traversal_criteria(
            in PdmContext pdm_context, in string traversal_name)
         raises (UnsupportedTraversalName);
   };


create_simple_traversal_criteria

The create_simple_traversal_criteria operation creates a simple CosGraphs::TraversalCriteria that facilitates navigating from a Node through a single Role, one level deep.  The Role type and desired PdmContext are specified as parameters to the operation.

create_named_traversal_criteria

The create_named_traversal_criteria operation creates a CosGraphs::TraversalCriteria with more functionality.  A Traversal may navigate and return CosGraphs::Edges for many Roles, and may continue to many levels of the relationship graph.  This allows the implementation of a wide range of functionality to meet business and performance goals.

The names of specific traversal criteria and their functionality are not standardized by the PDM Enablers specification at this time, and must be documented by individual PDM Enablers service providers.


Make the following changes to the IDL in section 2.6.4:

Add the following exception definition:
exception UnsupportedTraversalName
   {
      unsigned long error_code;
      string error_text;
   };

Change the definition of PdmContext to:
interface PdmContext {};

Add the following definition:
interface PdmTraversalCriteriaFactory
   {
      CosGraphs::TraversalCriteria create_simple_traversal_criteria(
            in PdmContext pdm_context, in CORBA::InterfaceDef role_type);
      CosGraphs::TraversalCriteria create_named_traversal_criteria(
            in PdmContext pdm_context, in string traversal_name)
         raises (UnsupportedTraversalName);
   };


Actions taken:

December 21, 1999: received issue

December 21, 1999: received issue

October 10, 2000: closed issue


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





Issue 3155: PdmContext is insufficient as a TraversalCriteria                                                                                                                                                       (pdm-rtf)

Click here for this issue's archive.


Source: Hewlett-Packard (Mr. Duane Silkworth, nobody duane.silkworth@eds.com)

Nature: Revision

Severity: Critical

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


Resolution: Duplicate of 3154. Closed

Revised Text: 

Actions taken:

October 10, 2000: closed issue



Issue 3309: Factories for non-abstract subtypes of Qualification                                                                                                                                                    (pdm-rtf)

Click here for this issue's archive.


Source: PROSTEP AG (Dr. Lutz Laemmer, lutz.laemmer@prostep.com Lutz.Laemmer@PROSTEP.com laemmer@prostep.de laemmer@prostep.com)

Nature: Uncategorized Issue

Severity: 

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



Resolution: accepted and resolved

Revised Text: 
In section 2.9.3.5 DatedEffectivity, and section 2.9.4 PdmEffectivity IDL, change interface DatedEffectivityFactory.

replace:
  interface DatedEffectivityFactory
  {
    DatedEffectivity create(
        in TimeBase::UtcT start_date,
        in TimeBase::UtcT end_date)
      raises (ITEM_CREATE_EXCEPTIONS);
  };

by:
  interface DatedEffectivityFactory
  {
    DatedEffectivity create(
      in CosPropertyService::PropertySet property_set)
      raises (ITEM_CREATE_EXCEPTIONS);
  };

In section 2.9.3.6 LotEffectivity, and section 2.9.4 PdmEffectivity IDL, change interface LotEffectivityFactory.
replace:
  interface LotEffectivityFactory
  {
    LotEffectivity create(
        in string lot_id,
        in PdmFoundation::Measurement lot_size)
      raises (ITEM_CREATE_EXCEPTIONS);
  };

by:
  interface LotEffectivityFactory
  {
    LotEffectivity create(
      in CosPropertyService::PropertySet property_set)
      raises (ITEM_CREATE_EXCEPTIONS);
  };


In section 2.9.3.7 SerialNumberEffectivity, and section 2.9.4 PdmEffectivity IDL, change interface SerialNumberedEffectivityFactory.

replace:
  interface SerialNumberedEffectivityFactory
  {
    SerialNumberedEffectivity create(
        in string start_id,
        in string end_id)
      raises (ITEM_CREATE_EXCEPTIONS);
  };

by:
  interface SerialNumberedEffectivityFactory
  {
    SerialNumberedEffectivity create(
      in CosPropertyService::PropertySet property_set)
      raises (ITEM_CREATE_EXCEPTIONS);
  };


In section 2.6.3.5 ViewQualification, and section 2.6.4 PdmViews IDL, change interface ViewQualificationFactory.

replace:
  interface ViewQualificationFactory
  {
    ViewQualification create( in string name)
        raises (ITEM_CREATE_EXCEPTIONS);
  };

by:
  interface ViewQualificationFactory
  {
    ViewQualification create(
      in CosPropertyService::PropertySet property_set)
      raises (ITEM_CREATE_EXCEPTIONS);
  };


In section 2.6.3.7 LifeCycleQualification, and section 2.6.4 PdmViews IDL, change interface LifeCycleQualificationFactory.

replace:
  interface LifeCycleQualificationFactory
  {
    LifeCycleQualification create( in string name )
      raises (ITEM_CREATE_EXCEPTIONS);
  };

by:
  interface LifeCycleQualificationFactory
  {
    LifeCycleQualification create(
      in CosPropertyService::PropertySet property_set)
      raises (ITEM_CREATE_EXCEPTIONS);
  };

In section 2.6.3.9 LocationQualification, and section 2.6.4 PdmViews IDL, change interface LocationQualificationFactory.

replace:
  interface LocationQualificationFactory
  {
    LocationQualification create( in string name )
      raises (ITEM_CREATE_EXCEPTIONS);
  };

by:
  interface LocationQualificationFactory
  {
    LocationQualification create(
      in CosPropertyService::PropertySet property_set)
      raises (ITEM_CREATE_EXCEPTIONS);
  };

In section 2.6.3.11 DisciplineQualification, and section 2.6.4 PdmViews IDL, change interface DisciplineQualificationFactory.

replace:
  interface DisciplineQualificationFactory
  {
    DisciplineQualification create(in string name)
      raises (ITEM_CREATE_EXCEPTIONS);
  };

by:
  interface DisciplineQualificationFactory
  {
    DisciplineQualification create(
      in CosPropertyService::PropertySet property_set)
      raises (ITEM_CREATE_EXCEPTIONS);
  };

In section 2.6.3.13 CompoundQualification, and section 2.6.4 PdmViews IDL, change interface CompoundQualificationFactory.

replace:
  interface CompoundQualificationFactory
  {
    CompoundQualification create()
      raises (ITEM_CREATE_EXCEPTIONS);
  };

by:
  interface CompoundQualificationFactory
  {
    CompoundQualification create(
      in CosPropertyService::PropertySet property_set)
      raises (ITEM_CREATE_EXCEPTIONS);
  };


Actions taken:

February 10, 2000: received issue

October 10, 2000: closed issue


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





Issue 3310: Factories to non-abstract subtypes of Effectivity                                                                                                                                                       (pdm-rtf)

Click here for this issue's archive.


Source: PROSTEP AG (Dr. Lutz Laemmer, lutz.laemmer@prostep.com Lutz.Laemmer@PROSTEP.com laemmer@prostep.de laemmer@prostep.com)

Nature: Uncategorized Issue

Severity: 

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



Resolution: See the resolution to issue 3309

Revised Text: 

Actions taken:

February 10, 2000: received issue

October 10, 2000: close dissue



Issue 3312:  ViewQualification is abstract                                                                                                                                                                          (pdm-rtf)

Click here for this issue's archive.


Source: PROSTEP AG (Dr. Lutz Laemmer, lutz.laemmer@prostep.com Lutz.Laemmer@PROSTEP.com laemmer@prostep.de laemmer@prostep.com)

Nature: Uncategorized Issue

Severity: 

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


Resolution: accepted in principle

Revised Text: in 2.6.3.5 ViewQualification, line 1
replace:
A ViewQualification is an abstract type of Qualification...
by:
A ViewQualification is a subtype of Qualification...


Actions taken:

February 10, 2000: received issue

October 10, 2000: closed issue


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