Issue 3090: Convention for Creating Items (pdm-rtf) Source: Hewlett-Packard (Mr. Duane Silkworth, nobody) Nature: Uncategorized Issue Severity: Summary: 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? Resolution: Revised Text: Actions taken: November 29, 1999: received issue October 10, 2000: issue deferred Discussion: 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. End of Annotations:===== Date: Mon, 29 Nov 1999 13:10:44 -0600 From: Duane Silkworth Reply-To: Duane.Silkworth@MetaphaseTech.com Organization: Metaphase Technology X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org CC: pdm_rtf@omg.org Subject: New issues for PDM RTF Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: ^Y"e909(!!5GI!!`^ To: "'Duane.Silkworth@MetaphaseTech.com'" , pdm-rtf@omg.org Subject: RE: PDM RTF V1.3 Ballot 1 Date: Tue, 16 May 2000 17:42:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: dL!!!%`Ne9'N-e9C9(!! Here is my vote for the ballot 1. for the issue 3090 - convention for creating items, I still think we might want to do something about it. deferred might be a better choice, but I guess we can always generate a similar issue later on when we get a handle on attribute issue. Lance Bao Information Technology C-17 Program, A&M Southern California The Boeing Company 2401 E. Wardlow Rd. MC C095-0031 Long Beach, CA 90807-5309 (562) 982-8558 (voice) (562) 982-8549 (fax) lance.y.bao@boeing.com > -----Original Message----- > From: Duane Silkworth [SMTP:Duane.Silkworth@MetaphaseTech.com] > Sent: Monday, May 15, 2000 11:21 AM > To: pdm-rtf@omg.org > Subject: PDM RTF V1.3 Ballot 1 > > PDM RTF V1.3 Ballot 1, May 15, 2000 > > Note: Changes in mfg/2000-05-02, May 15 compared to mfg/2000-0201, May 11 > are: > - Modified title page > - added material to front matter > - changed resolution of 3088 from "Accepted" to "Accepted in Principle" > - changed resolution of 3089 to "Unresolved". (A re-written resolution > may be forthcoming) > - Issue 3154 Corrected typo and wording in paragraph 2 of section 2.6.3.4. > > - Added resolution for duplicate issue 3155 > > For each open PDM Enablers issue, please record your vote on the > Resolution, Revised Text and Disposition as stated in OMG document > mfg/2000-05-02, PDM Enablers RTF Ballot Draft Report. > > > You may vote by replying to this email, and please cc: pdm-rtf@omg.org > > You must be a member of the RTF to vote. Members are listed on the OMG > web site at: > OMG TC Work in Progress > > > Indicate your Name and Company: > Name: [Bao, Lance Y] Lance Bao > Company: [Bao, Lance Y] The Boeing Company > > OMG Issue No: 1895 > Title: Alignment of OMG Person/Party models > Disposition: Deferred > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > OMG Issue No: 2485 > Title: PDM Enablers file locking behavior > Disposition: Deferred > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > > > OMG Issue No: 3084 > Title: Session Management > Disposition: Deferred > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > OMG Issue No: 3085 > Title: Authentication > Disposition: Deferred > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > OMG Issue No: 3086 > Title: Attributes > Disposition: Deferred > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > OMG Issue No: 3087 > Title: Workflow > Disposition: Deferred > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > OMG Issue No: 3088 > Title: Factory Finder Conventions > Disposition: Accepted in Principle > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > > OMG Issue No: 3089 > Title: IdentificationContext Conventions > Disposition: Deferred > [The resolution of this issue is still under discussion and is not > ready > for a vote.] > [Bao, Lance Y] ? is this defered or accepted ? > OMG Issue N o: 3090 > Title: Convention for Creating Items > Disposition: Rejected > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Abstain > > OMG Issue No: 3154 > Title: PdmContext is insufficient as a TraversalCriteria > Disposition: Accepted > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > OMG Issue No: 3155 > Title: PdmContext is insufficient as a TraversalCriteria > Disposition: Resolved by Issue 3154 > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] where is the text for this in the RTF 1.3 Reprot ? > > OMG Issue No: 3301 > Title: Vault object references > Disposition: Accepted > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > OMG Issue No: 3309 > Title: Factories for non-abstract subtypes of Qualification > Disposition: Accepted > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > > OMG Issue No: 3310 > Title: Factories to non-abstract subtypes of Effectivity > Disposition: Resolved by Issue 3309 > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > > OMG Issue No: 3311 > Title: ConfigurationItem > Disposition: Deferred > [choose one of YES, NO, ABSTAIN] > [Bao, Lance Y] Yes > OMG Issue No: 3312 > Title: ViewQualification is abstract. > Disposition: Accepted in Principle > [choose one of YES, NO, ABSTAIN] > > [Bao, Lance Y] Yes > > Date: Thu, 11 Jan 2001 15:24:40 +0100 From: Lutz Ldmmer X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Cc: jpdm.team@mscsoftware.com, issues@omg.org, pdm-rtf@omg.org Subject: Re: Issue log 2001-01-01_2200 References: <14930.18295.200062.879352@mouse.msid.cme.nist.gov> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 6__!!DOJe94!hd98(nd9 Hi, David Flater wrote: > ...non-related stuff deleted by LL > Issue 80, I don't see the RTF issue in the list at > http://cgi.omg.org/issues/pdm-rtf.html. > The corresponding issue is issue 3090 (Convention for Creating Items) Please add the following to the issue's discussion: Issue Summary from the JPDM v2.0 submission issue log: Need to be able to provide an ID when creating an object for transactional integrity. As it stands the creation of an object and the assignment of its ID is done in a minimum of two steps, leaving the object exposed to an invalid (unidentified) state if there is failure between the two or more operations. Proposal for Resolution Text to issue 3090: 1. The result of the Create method is a reference to a new CORBA object. This CORBA object may be or may not be the representation of one or more PDM data base objects. The client must not assume a particular configuration of constructed PDM data base objects but it is the freedom of the server implementation to construct as many PDM data base objects and their CORBA object representations as required by the underlying business model. For example, it is a valid behaviour of the PdmProductStructerDefinition::PartMasterFactory::create method to construct a single data base object and to return a reference to a PartMaster CORBA object which represents this data base object. Furthermore, the implemented business logic may imply from the existence of this data base object, that a corresponding tree with PartMasterComposition, PartRevision, PartDataRelationship, PartData, PartDataIterationRelationship, PartDataIteration becomes accesible by a graph traversal. A client should handle this situation. 2. If the specified attributes in the call to the create function match to an already existing CORBA object or would result in the construction of a CORBA object which represents an already existing PDM data base object the Exception NotUnique is thrown. Therefore, it is guaranteed to construct a new object (or a number of new objects) by the Create method. 3. Create and Bind are two distinct steps in the construction of an object. The Bind step is optional, e.g. objects implementing Identifiable may remain un-associated to a particular IdentificationContext (the cardinality of that role in the Identification-Relationship is *) or the server may perform an implicit Bind during the Create. There is no way for a client to force the server to perform the Bind. 4. A server which requires a particular attribute for the Create to succeed should throw the Exception InvalidProperties if that information is missing from the parameters to the Create method. The Exception InvalidProperties specifies the name and the data type of the missing attribute. There is no way to describe a valid range for an attribute (this might result in an issue against the InvalidProperties spec). Regards, -- ___________________________________________________________ ProSTEP Produktdatentechologie GmbH Geschdftstelle Hannover Dr. Lutz Laemmer Phone: +49-511-540 58 101 Karl-Wiechert-Allee 72 Mobil: +49-172-682 56 10 D-30625 Hannover Fax: +49-511-540 58 150 Email: laemmer@prostep.de ___________________________________________________________ From: David Flater MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: <14941.58190.608659.51834@mouse.msid.cme.nist.gov> Date: Thu, 11 Jan 2001 11:46:06 -0500 (EST) To: Lutz Ldmmer Cc: jpdm.team@mscsoftware.com, issues@omg.org, pdm-rtf@omg.org Subject: Re: Issue log 2001-01-01_2200 In-Reply-To: <3A5DC228.83803A75@prostep.de> References: <14930.18295.200062.879352@mouse.msid.cme.nist.gov> <3A5DC228.83803A75@prostep.de> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-Public-Key: Available at http://www.mel.nist.gov/msidstaff/flater/flater.htm X-Keyserver: wwwkeys.pgp.net Content-Type: text/plain; charset=us-ascii X-UIDL: 9F$e9Q5Yd9a$#e9`3Ne9 Lutz, Speaking as the testability guy, I have reservations about your proposed resolution to issue 3090. 1. The sub-issue about an interoperable client being able to create things without prior knowledge about what needs to be in the PropertySet was not addressed. I agree with the issue text, which says "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." The proposal instead leaves the client guessing at properties and getting exceptions that say "Wrong, try again." 2. The manner in which an initial ID is given to an Identifiable was left ambiguous. The proposal clarifies that this may happen implicitly, but it does not specify that it will happen and it does not clarify how a client could specify an IdentificationContext in the PropertySet. 3. An awful lot of ambiguity has been forced on the client via "A client should handle this situation," and it's not always clear that it's feasible for an interoperable client to do this. Either the client needs to probe the PDM before every create to determine whether the object it was about to create already exists, or it needs to go ahead and try to create it and then get this exception: > 2. If the specified attributes in the call to the create function match > to an already existing CORBA object or would result in the construction > of a CORBA object which represents an already existing PDM data base > object the Exception NotUnique is thrown. Unfortunately I don't see how you can determine whether a new, as-yet-unidentified object is a duplicate or not. For example, suppose that when I created a PartMaster I secretly also got a PartRevision. Now I go to create a PartRevision. Won't I just end up with Rev #2 of the Part instead of a NotUnique exception? In summary, I think we have the same problem here that we have with IdentificationContext, which is that implementation details are being forced on the client instead of mapped to a standard behavior. I would propose instead that the inputs and results of create operations should be specified more strongly, as the issue seemed to request. Regards, DWF Date: Fri, 12 Jan 2001 11:36:35 +0100 From: Lutz Ldmmer X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Cc: jpdm.team@mscsoftware.com, issues@omg.org, pdm-rtf@omg.org Subject: Re: Issue log 2001-01-01_2200 References: <14930.18295.200062.879352@mouse.msid.cme.nist.gov> <3A5DC228.83803A75@prostep.de> <14941.58190.608659.51834@mouse.msid.cme.nist.gov> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: YKpd9T\!"!8E!e9Bi]!! Dear All, David Flater wrote: > > Lutz, > > Speaking as the testability guy, I have reservations about your > proposed resolution to issue 3090. > > 1. The sub-issue about an interoperable client being able to create > things without prior knowledge about what needs to be in the > PropertySet was not addressed. I agree with the issue text, which > says "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 is not feasible always to "default to reasonable values depending on the site's business requirements". It is feasible in an offline data exchange scenario (using STEP) but it is not feasible in an operational environment with online access to a PDM system. > The proposal instead leaves the client guessing at > properties and getting exceptions that say "Wrong, try again." This is certainly true but due to limitations to be resolved by the PDME V2.0 Profile information. A profile should give a client the possibility to obtain information in advance which parameters have to be passed to the create method. > > 2. The manner in which an initial ID is given to an Identifiable was > left ambiguous. The proposal clarifies that this may happen > implicitly, but it does not specify that it will happen and it does > not clarify how a client could specify an IdentificationContext in the > PropertySet. It is left intentionally ambiguous. Unfortunately, if you try to invent some language to specify, which attributes of which interface (in which relation to the interface you are constructing with that factory) and which associations you want to populate you end up with the definition of a data model. > > 3. An awful lot of ambiguity has been forced on the client via "A > client should handle this situation," and it's not always clear that > it's feasible for an interoperable client to do this. I meant, the client should be robust enough not to fail in such a situation, e.g. the client programmer should be aware that this might happen. I didn't meant the client should manage this situation and force any special business rule to take effect. > Either the > client needs to probe the PDM before every create to determine > whether > the object it was about to create already exists, or it needs to go > ahead and try to create it and then get this exception: Well, there is no "probe" function. CORBA works in the try-catch manner. (Profiles can help in this situation.) > > 2. If the specified attributes in the call to the create function match > > to an already existing CORBA object or would result in the construction > > of a CORBA object which represents an already existing PDM data base > > object the Exception NotUnique is thrown. > Unfortunately I don't see how you can determine whether a new, > as-yet-unidentified object is a duplicate or not. This depends on the business scenario and the internal structure of the PDM system, both should not be exposed. In general, I see two options: 1. Either all identifying attributes (keys in data base terminology) are not candidates for parameters to the create function and the create will never throw NotUnique. Identifying attributes are handled by the bind method only, which might throw NotUnique. 2. Key attributes and possibly ID are valid parameter to the create function and the server may check for uniqueness, perform implicit bind and so on. Option 1 is the clean approach which would be the ideal. Option 2 is the real world and PDM systems I know of are using all the possible combinations. > For example, > suppose that when I created a PartMaster I secretly also got a > PartRevision. Now I go to create a PartRevision. Won't I just end > up > with Rev #2 of the Part instead of a NotUnique exception? The usage guide should avoid this ambiguity by recommending the exclusive use of the generate_new_revision/iteration. The problem remains, how the client tracks the incarnation of the first revision/iteration. Unfortunately, during our experiences with PDM Enablers implementations all possibilities seem to happen in the existing systems: Some systems require the ID the same time the object is created, others do not support object creation without bind. The combinations, which part of the master/revision/iteration tree is constructed vary as well. If a PDM system does not have a general data slot representing some "PartMaster" data but stores always all master information as copy with all Iterations, then we will never have a single PartMaster but always the complete tree down to the Iteration. If a PDM system supports Master-information but imposes other cardinality constraints on the Master-Revision relationship than the PDM enablers spec, than a PartMaster may not come into life without a PartRevision... You may experience more variants. > > In summary, I think we have the same problem here that we have with > IdentificationContext, which is that implementation details are > being > forced on the client instead of mapped to a standard behavior. I > would propose instead that the inputs and results of create > operations > should be specified more strongly, as the issue seemed to request. This might result in the definition of the underlying data model. I wouldnt expect this to be the intent of the author of the issue. How about the position of the PDM vendors on this mailing list? Regards, Lutz -- ___________________________________________________________ ProSTEP Produktdatentechologie GmbH Geschdftstelle Hannover Dr. Lutz Laemmer Phone: +49-511-540 58 101 Karl-Wiechert-Allee 72 Mobil: +49-172-682 56 10 D-30625 Hannover Fax: +49-511-540 58 150 Email: laemmer@prostep.de ___________________________________________________________