Issue 3089: IdentificationContext Conventions (pdm-rtf) 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 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!!`^ Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by emerald.omg.org id IAA05426 Content-Type: text/plain; charset=ISO-8859-1 X-UIDL: R$]d9-;X!!OI1!!)7*e9 Title: IdentificationContext Conventions (Issue number 3089) - Discussion of issue. Note: this is a discussion statement and not a definite proposal for issue resolution. It seems that there are two separate, but related, issues here. Firstly, the syntax for the names of IdentificationContexts, i.e. how should the name, and naming components (if any), be represented? Secondly, meaning conveyed by each naming component? How many naming components should there be and what should they mean? The solution to the first issue seems easy. One of two mechanisms (currently used by the Identifiable interface for object ids) could be adoptedThe name is represented by a sequence of strings, each representing a single naming component. Semantics of IdentificationContext naming components. It seems to me that ItentificationContext names could be made up of three components: Typeof identified object - i.e. different identification contexts could exist for identifying different types of objects. For example: ids for documents and parts may be generated in a way that guarantees uniqueness of each document amongst other documents and each part amongst other parts. However the uniqueness may not be guaranteed for both parts and documents. There could exist documents with the same ids as some parts, in which case only the context would provide a way of differentiating which is which. But what should be used as the basis for generating IdentificationContext names based on type? Should the PDM- E IDL types be used for this purpose (e.g. PartMaster, PartRevision etc.) or perhaps the types should more closely reflect objects as seen by the business (Part, Document, Person etc.)? 2) Different companies will provide different conventions for generating ids. An id generated by one company cannot be guaranteed to be unique and/or meaningful inside a different company. 3) Any one company may have several conventions for generating ids for their information, perhaps depending on the purpose of the generated information, or on the department/division that generated the id. To make things more complicated each department/division could have several conventions for generating ids. The three componentobjects (this perhaps should include and departmental information from within the company). A scheme via used by the company/person/system to generate ids. Some schemes might be based on international standards others may be proprietary. A template for generating IdentificationContext names could look like this: Type_name::Company_name::division_name::sub_division_name::e ct::id_naming_scheme Here is an example of a valid name based on that template: s of an IdentificationContext object could be: Type of Identified object (based on DP Default IdentificationContext names: Should identification context names have default values? Which of the above three components (if any, or maybe all) should be included in the default value? The issue suggests that sites supporting a single identification context pert item type (IDL type or business type?) the name of the identification context should be the same as the name of the type of the object identified. E.g. valid identification context names could be M-E IDL type or another typing scheme) Company (or eP, rson or System) that generates the I.D etc. Availability of IdentificationContext names: Should an IdentificationContextFactory (or any other interface) contain a method for returning all possible IdentificationContext names associated with an object, a type or a system? _________________________________________________________ Peter Dziulka Consultant Software Engineer, Enabled Systems, 6 Blenheim Terrace, Leeds LS6 9HZ, UK. E-mail: pete@caddetc.co.uk Tel: +44 (0)113 245 2288; Fax: +44 (0)113 246 8492 URL: http://www.caddetc.co.uk/enabled-systems/ _________________________________________________________ These are: The name of the IdentificationContext is represented by a single string, where each naming component is separated by a double colon :: From: pete@caddetc.co.uk To: pdm-rtf@omg.org Date: Fri, 18 Feb 2000 14:03:16 -0000 MIME-Version: 1.0 Subject: Issue 3089: IdentificationContext Conventions: Resolution Proposal Priority: normal X-mailer: Pegasus Mail for Win32 (v3.11) Message-Id: <14034346800316@caddetc.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by emerald.omg.org id JAA06396 Content-Type: text/plain; charset=ISO-8859-1 X-UIDL: 2:)!!"GGe9T#Ne9i1#e9 Issue 3089: IdentificationContext Conventions Proposed Resolution: The proposed resolution is partly a result of a discussion, which took place during a teleconference on 09-Feb-2000. I think it was generally agreed that: 1) It ithe time of writing the standard, because IdentificationContext names can be business and/or company specific. It follows that any solution to this issue must involve a mechanism to make IdentificationContext names available to clients at run time. I suggest that IdentificationContextFactory interface, which currently supports two operations create(in CosPropertyService::PropertySet property_set) and find_id_context(in string the_context_name) is extended to support a third operation. This operation would return a sequence of names of all IdentificationContexts supported by the PDM system. Note that this operation should not return a sequence of IdentificationContext object references, because IdentificationContext interface does not support an operation (either directly or by inheritance) to return its own name/identifier (therefore one IdentificationContext ithe time of writing the standard, because IdentificationContext names can be business and/or company specific. It follows that any solution to this issue must involve a mechanism to make IdentificationContext names available to clients at run time. I suggest that IdentificationContextFactory interface, which currently supports two operations create(in CosPropertyService::PropertySet property_set) and find_id_context(in string the_context_name) is extended to support a third operation. This operation would return a sequence of names of all IdentificationContexts supported by the PDM system. Note that this operation should not return a sequence of IdentificationContext object references, because IdentificationContext interface does not support an operation (either directly or by inheritance) to return its own name/identifier (therefore one IdentificationContext is not easily distinguishable from another). ****************************** Content and meaning of IdentificationContext names: I propose that IdentificationContext names should contain at least two pieces of information. These should be: 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 InformationContext. 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. For example, the client might expect an object reference of type PdmProductStructure::PartMaster, PdmDocumentManagement::DocumentMaster or PdmDocumentManagement::Vault. The type of object reference expected by the client should be specified as part of IdentificationContext name. There exists only a handful of object types for objects whose references are obtained via the IdentificationContext/Identifier mechanism. All such types should be identified as part of the standard. These will be: PdmProductStructure::PartMaster, PdmDocumentManagement::DocumentMaster, PdmDocumentManagement::Vault and possibly a handful of others. Note that some PDM system implementations might support multiple IdentificationContexts. By that I understand that these implementations will not support BUSINESS RELATED IdentificationContexts. I assume that these PDM systems will hold information about objects from several IDL types mentioned above (Parts, Vaults and Documents). Therefore, these PDM systems support (implicitly) several IdentificationContexts of the second kind. ****************************** Structure of IdentificationContext names: I propose use the CosNaming::NameComponent type for representing IdentificationContext names. Struct NameComponent { Istring id; Istring kind; } the id field should be used to represent business related IdentificationContext name, while the kind field should represent the IDL type of the expected information. Note: During the teleconference held on Tuesday 22nd of February 2000 it was suggested that default IdentificationContext names should simply be represented by blank strings. ****************************** Proposed changes to IDL Module PdmFoundation { . . stuff . . typedef CosNaming::NameComponent IdentificationContextName; //addition typedef sequence< IdentificationContextName> IdentificationContextNames; //addition 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); //change IdentificationContextNames find_id_context_names(); //addition } . stuff . } _________________________________________________________ Peter Dziulka Consultant Software Engineer, Enabled Systems, 6 Blenheim Terrace, Leeds LS6 9HZ, UK. E-mail: pete@caddetc.co.uk Tel: +44 (0)113 245 2288; Fax: +44 (0)113 246 8492 URL: http://www.caddetc.co.uk/enabled-systems/ _________________________________________________________ s not easily distinguishable from another). ****************************** Content and meaning of IdentificationContext names: I propose that IdentificationContext names should contain at least two pieces of information. These should be: 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 InformationContext. 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. For example, the client might expect an object reference of type PdmProductStructure::PartMaster, PdmDocumentManagement::DocumentMaster or PdmDocumentManagement::Vault. The type of object reference expected by the client should be specified as part of IdentificationContext name. There exists only a handful of object types for objects whose references are obtained via the IdentificationContext/Identifier mechanism. All such types should be identified as part of the standard. These will be: PdmProductStructure::PartMaster, PdmDocumentManagement::DocumentMaster, PdmDocumentManagement::Vault and possibly a handful of others. Note that some PDM system implementations might support multiple IdentificationContexts. By that I understand that these implementations will not support BUSINESS RELATED IdentificationContexts. I assume that these PDM systems will hold information about objects from several IDL types mentioned above (Parts, Vaults and Documents). Therefore, these PDM systems support (implicitly) several IdentificationContexts of the second kind. ****************************** Structure of IdentificationContext names: I propose use the CosNaming::NameComponent type for representing IdentificationContext names. Struct NameComponent { Istring id; Istring kind; } the id field should be used to represent business related IdentificationContext name, while the kind field should represent the IDL type of the expected information. ****************************** Proposed changes to IDL Module PdmFoundation { . . stuff . . typedef CosNaming::NameComponent IdentificationContextName; //addition typedef sequence< IdentificationContextName> IdentificationContextNames; //addition 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); //change IdentificationContextNames find_id_context_names(); //addition } . stuff . } _________________________________________________________ Peter Dziulka Consultant Software Engineer, Enabled Systems, 6 Blenheim Terrace, Leeds LS6 9HZ, UK. E-mail: pete@caddetc.co.uk Tel: +44 (0)113 245 2288; Fax: +44 (0)113 246 8492 URL: http://www.caddetc.co.uk/enabled-systems/ _________________________________________________________ s necessary for a client to know the name of an IdentificationContext, before any object can be found in the PDM system. 2) It From: pete@caddetc.co.uk To: pdm-rtf@omg.org Date: Fri, 3 Mar 2000 14:35:31 -0000 MIME-Version: 1.0 Subject: Issue 3089: IdentificationContext Conventions - revised following teleconf. Priority: normal X-mailer: Pegasus Mail for Win32 (v3.11) Message-Id: <14364840500005@caddetc.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by emerald.omg.org id JAA05662 Content-Type: text/plain; charset=ISO-8859-1 X-UIDL: NDYd9'8a!!hm#e9G,/e9 Issue 3089: IdentificationContext Conventions Updated, as agreed in at the teleconference held on 22 Feb. 2000 Proposed Resolution: The proposed resolution is partly a result of a discussion, which took place during a teleconference on 09-Feb-2000. I think it was generally agreed that: 1) It is necessary for a client to know the name of an IdentificationContext, before any object can be found in the PDM system. 2) It Date: Mon, 15 May 2000 09:13:55 -0500 From: Duane Silkworth Reply-To: Duane.Silkworth@MetaphaseTech.com Organization: Metaphase Technology X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Lutz Ldmmer" , pdm-rtf@omg.org Subject: Issue 3089 and Re: Preparation for PDM RTF Ballot 1 References: <391C490A.1AA8111A@MetaphaseTech.com> <391FBF57.C2BCF795@prostep.de> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: UoOe914B!!h!pd9Qe[d9 "Dr. Lutz Ldmmer" wrote: > Duane, > Ed, > > I will be available this week (15-19 June) for email balloting. > > I agree with the current RTF report in principal but I have problems > with the resolution to issue 3089 (see my remarks below). I am not > aware > of some discussion on this topic after the Denver meeting. > Unfortunately, > the omg web site is not accessible, either. I am proposing > postponing > the > decision on this accepted (how?) issue. > > Regards, > > Lutz Doug, Pete, Do you have comments or suggestions in response to Lutz's suggestions below? I'll leave issue 3089 off the ballot until we have reached a consensus on it, but I am hopeful that we may yet be able to do so this week. To this end, here's some more email discussion, and I'll also arrange a telecon. How about this week Wednesday, May 17, 10:30 Central Daylight time? Pete's proposal had two parts: a) Changing the form of an id context name to be a CosNaming::NameComponent rather than a string. This allows us to have both a business-oriented name and a IDL type. As I understand it, neither Lutz ror anyone else objects to this. As devil's advocate though, it occurs to me that we could use a full hierarchical CosNaming::Name (a sequence of NameComponent). Would this give us more flexibility or consistency? b) An operation to return all the id context names. Lutz raises 3 points. > > > 1. To my knowledge, the IdentificationContext has an attribute name. > This attribute is read/write, and the IDL-Compiler should >generate > appropriate access functions. So, the last paragraph before the > heading "Content and meaning..." in the resolution section states > wrongly: > "...IdentificationContext interface does not support an operation >to > return its > own name/identifier..." > > 2. I support the highlighted DAS concerns. There are indeed quite a >few > (more than > 15) entities supporting the identifiable interface. > > 3. Instead of retrieving an arbitrary set of >IdentificationContextNames > I would like > to have a method to retrieve references to >IdentificationContext's > for a well > defined interface type, e.g. a function > IdentificationContextSeq find_id_context(in Istring repositoryID) > The parameter repositoryID identifies the interface to be >referenced > by the IdentificationContext > and a sequence of some/all IdentificationContext's associated >with > interfaces of that > particular type is returned. > > This proposal would allow to hide the implementation details for > managing > IdentificationContext names and it will be an extension of the > previous specification. > > This proposal avoids the problems of the proposal with > one single (default) context for all Identifiables (a blank >string > might > not make much sense, as proposed in the revised text). > > This proposal allows multiple IdentificationContext to be >associated > to multiple > Interface types, e.g. a Context PartIdentifiable to be used to > identify > PartMaster, PartRevision, PartStructureIteration, and > PartDataIteration. But, again > these details are transparent to the client. > > ... > ___________________________________________________________ > ProSTEP Produktdatentechologie GmbH Geschdftstelle Hannover > Dr. Lutz Laemmer Phone: +49-511- 540 58 101 > Karl-Wiechert-Allee 72 Fax: +49-511- 540 58 150 > D-30625 Hannover Email: laemmer@prostep.de > ___________________________________________________________ It occurs to me that it may be useful to have both the general functionality that Pete originally suggested: IdentificationContextNames find_id_context_names(); plus the operation that Lutz suggests: IdentificationContextSeq find_id_context(in Istring repositoryID) (where repositoryID is the IDL type of the Identifable The find_id_context operation would indeed be useful for clients that already know which type of object they wish to identify or retrieve. Lutz, in regard to your point (1), are you referring to the IdentificationContext::id attribute?. It is just a string, though, not a NameComponent. If we changed it to be a NameComponent, would that help? Duane -- Duane A. Silkworth Metaphase Technology Division, SDRC 4233 Lexington Avenue North, Suite 3290 Arden Hills, MN 55126-6198 voice:651-482-4140 fax:651-482-4001 mailto:Duane.Silkworth@MetaphaseTech.com http://www.metaphasetech.com Date: Tue, 16 May 2000 11:10:35 -0500 From: Duane Silkworth Reply-To: Duane.Silkworth@MetaphaseTech.com Organization: Metaphase Technology X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pdm-rtf@omg.org Subject: Issue 3089 Content-Type: multipart/mixed; boundary="------------4D038EFFB60B8A5B2BAC8952" X-UIDL: n!~!!LU_!!RTm!!fRD!! I've taken the previous solution writeup for Issue 3089, incorporated Lutz's suggestions, made some choices, changed some operation names, added exceptions, and condensed it to essentials. Other opinions may vary and are encouraged. Proofreading is also encouraged. Some topics: Should we change the id field of IdentificationContext to be a NameComponent? Should it even be a full Name? Should the new find operations return names or IdentificationContext object references? Should the type parameter in find_identification_contexts be specified as string or as InterfaceDef? Duane -- Duane A. Silkworth Metaphase Technology Division, SDRC 4233 Lexington Avenue North, Suite 3290 Arden Hills, MN 55126-6198 voice:651-482-4140 fax:651-482-4001 mailto:Duane.Silkworth@MetaphaseTech.com http://www.metaphasetech.com [] Issue 3089.doc Date: Thu, 18 May 2000 11:32:03 +0200 From: "Dr. Lutz Ldmmer" Organization: ProSTEP GmbH X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: pdm-rtf@omg.org Subject: Re: Telecon results, Issue 3089 References: <3922D238.62B90999@MetaphaseTech.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: W~!"!d>5e9)#%!!AF4e9 Hi Duane, the proposal is now in a pretty good shape. Comparing the issue summary and the proposed solution I miss the definition of the NameComponent instantiation for the default context and the one context per item only cases. The revised text does not define the id-component to be blank. Regards, Duane Silkworth schrieb: > > PDM RTF members: > > Only Pete D. from Enabled Systems and myself were on the official PDM RTF telecon at 10:30 CDT, 11:30 EDT today. We discussed the proposed language for issue 3089 Identification Context Conventions and thought that it was probably acceptable. I sent this in previous email. Please look it over closely and send any corrections or suggestions to me and the pdm-rtf list today - before tomorrow May 18 8:00 am CDT. I will then send out ballot 2 tomorrow morning. You will have only Thurs, Friday and the weekend to vote on ballot 2. > > Ed Barkmeyer missed the telecon before it adjourned, but then called me directly, and we had a little co-chairs discussion, and agreed to the above. We agreed that it would be best to still try to get a draft of the final report on the server by Monday May 22 for the three-week rule. We then have some options, along with several procedural challenges for the Oslo meeting. (The RTF expires on the Monday for the TC meeting, neither Ed not I will be there, etc...) > > Issue 3090 - Convention for Creating Items. > On ballot 1, this has a disposition of rejected. So far, the votes are 3 Abstain, and one Yes. Lance suggests leaving it open, and deferring it. Ed and I agree. So, Ed and I intend to vote NO to the ballot 1 issue 3090 language, and are recommending that others do the same. > > Issue 3090 will then be on Ballot 2 tomorrow with will have slghtly different resolution text and disposition=deferred. > > So: > Send your votes for ballot 1 if you have not done so. > Review Issue 3098 closely and send comments before 8:00 AM. > Ballot 2 will be distributed tomorrow morning with both issues 3089 and 3090. > Voting for both ballots closes Monday May 22 8:00 CDT, 9:00 EDT. > A final report will be on the server Monday May 22 before 5:00 PM EDT. > > Duane > > -- > Duane A. Silkworth > Metaphase Technology Division, SDRC > 4233 Lexington Avenue North, Suite 3290 > Arden Hills, MN 55126-6198 > voice:651-482-4140 fax:651-482-4001 > mailto:Duane.Silkworth@MetaphaseTech.com > http://www.metaphasetech.com -- ___________________________________________________________ ProSTEP Produktdatentechologie GmbH Geschdftstelle Hannover Dr. Lutz Laemmer Phone: +49-511- 540 58 101 Karl-Wiechert-Allee 72 Fax: +49-511- 540 58 150 D-30625 Hannover Email: laemmer@prostep.de ___________________________________________________________ From: pete@caddetc.co.uk Received: from [195.92.46.132] by cadnt1.caddetc.co.uk (NTMail 3.03.0018/1.ahnk) with ESMTP id ya025816 for ; Thu, 18 May 2000 13:24:17 +0100 To: pdm-rtf@omg.org Date: Thu, 18 May 2000 13:23:37 +0100 MIME-Version: 1.0 Content-transfer-encoding: 7BIT Subject: Re: Telecon results, Issue 3089 Priority: normal X-mailer: Pegasus Mail for Win32 (v3.11) Message-Id: <12241776302003@caddetc.co.uk> Content-Type: text/plain; charset=US-ASCII X-UIDL: <'Pe9l*$!!+/1e9kJL!! Hi Duane, I think I am inclined to agree with the proposal in its current form. Regards, Peter Dziulka _________________________________________________________ Peter Dziulka Consultant Software Engineer, Enabled Systems, 6 Blenheim Terrace, Leeds LS6 9HZ, UK. E-mail: pete@caddetc.co.uk Tel: +44 (0)113 245 2288; Fax: +44 (0)113 246 8492 URL: http://www.caddetc.co.uk/enabled-systems/ _________________________________________________________ Date: Thu, 18 May 2000 10:04:01 -0500 From: Duane Silkworth Reply-To: Duane.Silkworth@MetaphaseTech.com Organization: Metaphase Technology X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pdm-rtf@omg.org Subject: [Fwd: issue 3089] Content-Type: multipart/mixed; boundary="------------1162C5E2F0E7AEA895CA17A2" X-UIDL: V:T!!6'^!!(Vjd9l$0!! Lutz, To get your comments and the proposed text for 3089 in front of the RTF, I am forwarding them before I get your response. Anyone who wishes to chime in, please do so fast! We want to get ballot 2 out early today, if possible, with 3089 and 3090. If you have not voted on ballot one, please do so. Ed and I recommend a No vote on Ballot 1 Issue 3090-reject so we can reissue it in Ballot 2 as "Deferred". If anyone wishes to change your previous vote, go ahead. Duane -- Duane A. Silkworth Metaphase Technology Division, SDRC 4233 Lexington Avenue North, Suite 3290 Arden Hills, MN 55126-6198 voice:651-482-4140 fax:651-482-4001 mailto:Duane.Silkworth@MetaphaseTech.com http://www.metaphasetech.com X-Mozilla-Status2: 00000000 Message-ID: <3923FD55.BE8D057F@MetaphaseTech.com> Date: Thu, 18 May 2000 09:25:25 -0500 From: Duane Silkworth Reply-To: Duane.Silkworth@MetaphaseTech.com Organization: Metaphase Technology X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dr. Lutz Ldmmer Subject: Re: issue 3089 References: <3923BA11.B8A11AFF@prostep.de> Content-Type: multipart/alternative; boundary="------------E712FA177F8F1CA1AD38E616" Lutz, your message to the RTF said: the proposal is now in a pretty good shape. Comparing the issue summary and the proposed solution I miss the definition of the NameComponent instantiation for the default context and the one context per item only cases. The revised text does not define the id-component to be blank. The Revised Text has this paragraph in the description of the NameComponent. Is this OK? 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 may be represented by a blank string. "Dr. Lutz Ldmmer" wrote: Duane, I would like to ask you for reviewing my extra remarks before posting them to the RTF. I am not certain that my english is exact enough... 1. How would a implementation look like supporting just one single identification context for all identifiables? Straightforward, it will provide a single identification context with the NameComponent {"","IDL.omg.org:PdmFoundation/Identifiable:1.0"}. What will be the answer for find_id_contexts("IDL.omg.org:PdmProductStructureDefinition/PartMaster:1.0")? The Metaphase implementation does not do this, and I have not thought about it much. We have a separate IdentificationContext for each kind of Identifiable. But I guess it could work. Does your implementation do this? Do you have specific language to propose? I'd gladly put it in. I suppose that find_id_contexts("IDL.omg.org:PdmProductStructureDefinition/PartMaster:1.0") could return the one identification context that exists, which is capable of finding any Identifiable. Then, one would assume that PartMasters must be fully differentiated from other types of items by their IdentifierSeq (id). Alternatively, I would be agreeable to entirely disallowing this case, depending on what you wish.. 2. Will grouping of items by IdentificationContext into sets different from the possible groupings defined by the IDL inheritance tree be intentionally avoided? (e.g. PartMaster, PartRevision, Part-Iteration in one context and all Documents in the other context). Again, I see why this would be useful, but do not personally need to be able to do this. I believe, some more wording and explanation to the current proposal will resolve the concerns mentioned. Instead of confusing the RTF and preventing the good proposal going through I would like to discuss this matter with you only, first. Here's some proposed language. Does this capture what you mean? add this to the IdentificationContext description: Implementations may support separate IdentificationContext for each Identifiable type, or may support one or more IdentificationContexts that support multiple types of Identifiable object. All Identifiable items supported by a single IdentificationContext must be uniquely identified by their id within the IdentificationContext. In the description of the NameComponent kind field: The kind field indicates the type of the Identifiable objects managed by the IdentificationContext. If the IdentificationContext supports a single type or supertype of Identifiable Item, the kind field has the form of the interface repository RepositoryId for the InterfaceDef of the Identifiable object. If an 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 kind field may be implementation dependent. 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. Regards, -- ___________________________________________________________ ProSTEP Produktdatentechologie GmbH Geschdftstelle Hannover Dr. Lutz Laemmer Phone: +49-511- 540 58 101 Karl-Wiechert-Allee 72 Fax: +49-511- 540 58 150 D-30625 Hannover Email: laemmer@prostep.de ___________________________________________________________ -- Duane A. Silkworth Metaphase Technology Division, SDRC 4233 Lexington Avenue North, Suite 3290 Arden Hills, MN 55126-6198 voice:651-482-4140 fax:651-482-4001 mailto:Duane.Silkworth@MetaphaseTech.com http://www.metaphasetech.com [] Issue 3089 Ballot2.doc Date: Thu, 18 May 2000 10:39:26 -0500 From: Duane Silkworth Reply-To: Duane.Silkworth@MetaphaseTech.com Organization: Metaphase Technology X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Lutz Ldmmer" , pdm-rtf@omg.org Subject: Re: issue 3089 References: <3923BA11.B8A11AFF@prostep.de> <3923FD55.BE8D057F@MetaphaseTech.com> <39240643.F22DBD45@prostep.de> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: !2W!!kO;!!E7m!!UlG!! "Dr. Lutz Ldmmer" wrote: > Duane, > > Duane Silkworth schrieb: > > > > Lutz, your message to the RTF said: > > > > > the proposal is now in a pretty good shape. Comparing the issue >summary > > > and the > > > proposed solution I miss the definition of the NameComponent > > > instantiation for the > > > default context and the one context per item only cases. The >revised > > > text does not define > > > the id-component to be blank. > > > > > > > The Revised Text has this paragraph in the description of the > > NameComponent. Is this OK? > > > > 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 may be >represented > > by a blank string. > > How about replacing "may be" by "is". OK. > > > > > > "Dr. Lutz Ldmmer" wrote: > > > > > Duane, > > > > > > I would like to ask you for reviewing my extra remarks before > > > posting > > > them to the > > > RTF. I am not certain that my english is exact enough... > > > > > > 1. How would a implementation look like supporting just one >single > > > identification > > > context for all identifiables? Straightforward, it will provide >a > > > single > > > identification context > > > with the NameComponent > > > {"","IDL.omg.org:PdmFoundation/Identifiable:1.0"}. What will be >the > > > answer for > > > find_id_co > > > >texts("IDL.omg.org:PdmProductStructureDefinition/PartMaster:1.0")? > > > > The Metaphase implementation does not do this, and I have not >thought > > about it much. We have a separate IdentificationContext for each >kind > > of Identifiable. But I guess it could work. Does your >implementation > > do this? > > No, it doesn't, but somebody might come up with such an idea. > > > > > Do you have specific language to propose? I'd gladly put it in. >I > > suppose that > > >find_id_contexts("IDL.omg.org:PdmProductStructureDefinition/PartMaster:1.0") > > could return the one identification context that exists, which is > > capable of finding any Identifiable. Then, one would assume that > > PartMasters must be fully differentiated from other types of items >by > > their IdentifierSeq (id). > > > > Alternatively, I would be agreeable to entirely disallowing this >case, > > depending on what you wish. > > I would allow this behaviour. > > > > > > > > > > > > > > 2. Will grouping of items by IdentificationContext into sets > > > different > > > from the possible > > > groupings defined by the IDL inheritance tree be intentionally > > > avoided? > > > (e.g. PartMaster, PartRevision, Part-Iteration in one context >and > > > all > > > Documents in the other > > > context). > > > > Again, I see why this would be useful, but do not personally need >to > > be able to do this. > > > > > > > > > > > I believe, some more wording and explanation to the current >proposal > > > > > > will resolve > > > the concerns mentioned. Instead of confusing the RTF and >preventing > > > the > > > good proposal > > > going through I would like to discuss this matter with you only, > > > first. > > > > Here's some proposed language. Does this capture what you mean? > > Yes, it does indeed. I'm fine with your proposal and confident we >found > an agreement. > > > > > add this to the IdentificationContext description: > > > > Implementations may support separate IdentificationContext for >each > > Identifiable type, or may support one or more >IdentificationContexts > > that support multiple types of Identifiable object. All >Identifiable > > items supported by a single IdentificationContext must be uniquely > > identified by their id within the IdentificationContext. > > Well, the last sentence is already mentioned elsewhere. Yes. It's in the lead paragraph for Identifiable. In the interest of non-redundancy, I'll remove it from this paragraph. > > > > > > In the description of the NameComponent kind field: > > > > The kind field indicates the type of the Identifiable objects >managed > > by the IdentificationContext. If the IdentificationContext >supports a > > single type or supertype of Identifiable Item, the kind field has >the > > form of the interface repository RepositoryId for the InterfaceDef >of > > the Identifiable object. If an 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 kind field may be implementation dependent. > > > > 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. > > > -- > > Duane A. Silkworth > > Metaphase Technology Division, SDRC > > 4233 Lexington Avenue North, Suite 3290 > > Arden Hills, MN 55126-6198 > > voice:651-482-4140 fax:651-482-4001 > > mailto:Duane.Silkworth@MetaphaseTech.com > > http://www.metaphasetech.com > > > > BTW: It is very sad, that you are not attending the Oslo meeting. I > organiszed that PTC and possibly Dassault Systemes will show up! > > Regards, > -- > ___________________________________________________________ > > ProSTEP Produktdatentechologie GmbH Geschdftstelle Hannover > Dr. Lutz Laemmer Phone: +49-511- 540 58 101 > Karl-Wiechert-Allee 72 Fax: +49-511- 540 58 150 > D-30625 Hannover Email: laemmer@prostep.de > ___________________________________________________________ -- Duane A. Silkworth Metaphase Technology Division, SDRC 4233 Lexington Avenue North, Suite 3290 Arden Hills, MN 55126-6198 voice:651-482-4140 fax:651-482-4001 mailto:Duane.Silkworth@MetaphaseTech.com http://www.metaphasetech.com From: "Krisch, Dieter" To: "'Duane.Silkworth@MetaphaseTech.com'" Cc: "'pdm-rtf@omg.org'" Subject: RE: [Fwd: issue 3089] Date: Thu, 18 May 2000 17:42:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ;CF!!Ib:e9"K3e9#H;!! Hi RTF professionals, I change my "YES" vote on ballot 1 to "NO" on issue 3090. Greetings Dieter -----Original Message----- From: Duane Silkworth [mailto:Duane.Silkworth@MetaphaseTech.com] Sent: Donnerstag, 18. Mai 2000 17:04 To: pdm-rtf@omg.org Subject: [Fwd: issue 3089] Lutz, To get your comments and the proposed text for 3089 in front of the RTF, I am forwarding them before I get your response. Anyone who wishes to chime in, please do so fast! We want to get ballot 2 out early today, if possible, with 3089 and 3090. If you have not voted on ballot one, please do so. Ed and I recommend a No vote on Ballot 1 Issue 3090-reject so we can reissue it in Ballot 2 as "Deferred". If anyone wishes to change your previous vote, go ahead. Duane -- Duane A. Silkworth Metaphase Technology Division, SDRC 4233 Lexington Avenue North, Suite 3290 Arden Hills, MN 55126-6198 voice:651-482-4140 fax:651-482-4001 mailto:Duane.Silkworth@MetaphaseTech.com http://www.metaphasetech.com