Issue 4161: IdentificationContext Considered Harmful (pdm-rtf) Source: NIST (Mr. David Flater, dflater(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: Problem: 1. Confused "context" with "scope" The spec muddles the following two things together: - The need to maintain multiple identifiers for a single entity in different contexts: this Widget is known as Navy Part X, and also as Company Part Y. This is a user-level, real-world, business concept. - The need to qualify the identifiers of different entities based on their scopes: Document X is not the same entity as Part X, and Revision Z of Document X is not the same entity as Revision Z of Document Y. This is an implementation-level concept. Conceptually, the scoping of identifiers occurs within a context, but the spec requires us to create separate IdentificationContexts for every scope. A special case was made to allow Revisions to be implicitly scoped by their Master (Section 2.3.3.6, just above Implementation Issues). This is even worse because it violates the model of identification. An identifier is supposed to uniquely specify an entity within a context. If a Revision cannot be unambiguously retrieved using only a context and an identifier, then Revision should not inherit from Identifiable. If Revisions are identifiable, then their identifications probably consist of a revision number qualified by a path to the Master or by some other information that is sufficient to identify the scope. That is not to say that a user interface would force the user to specify anything more than the revision number once the scope of that session has been established. This is similar to the usage of relative path names in a file system. But in the current spec, a Revision is like some weird, special kind of file that exists within its directory if you go there first but cannot ever be accessed using a fully-qualified path. Consider the ramifications for application programmers. 2. High overhead A consequence of muddling scope with context is the proliferation of IdentificationContexts. A large number of these must be propagated into the Bill of Materials and retrieved and managed by every client program, no matter what the application. This creates special problems for query and traversal convenience functions because there is no convenient way to specify all of the needed IdentificationContexts. Alternately, in the case of implicit scoping, clients are unable to retrieve certain entities based on their identifications alone and must instead navigate from entities whose identifications are unambiguous. The client is forced to manage additional information and perform extra operations because the PDM does not maintain the uniqueness of identifiers. Clients should not be required to navigate to something that is Identifiable; they should be able to do a simple find-by-ID if an ID is what they've got. 3. Interoperable client not feasible A client cannot rely on find_id_context to locate a usable IdentificationContext without special knowledge about the implementation because both the existence of a default context and the set of kinds that have associated IdentificationContexts are implementation-dependent. Instead, an interoperable client must use find_id_contexts to retrieve a list of candidate IdentificationContexts for each interface type and then select among the candidates. The client is trying assemble the collection of IdentificationContexts that would correspond to a single context if scope and context were not intermingled. But since they are, there is no interoperable way to determine which set of IdentificationContexts is appropriate. If the client should luck into an appropriate set of IdentificationContexts, it still must somehow discover and conform to the implementation-dependent rules for the properties to pass to generate_id. There does not seem to be any interoperable way to do this either. 4. Implementation details are exposed The vendor's decision to use a single name space for all PDM objects or to use separate name spaces for every class of objects internal to the PDM is an implementation detail that need not be exposed and should not be exposed. Under the current spec, clients have the unenviable job of discovering and conforming to the internal name space structure of the PDM. They do not really benefit from the standardization of the interface because the behavior is still different for each implementation. Instead, the implementation details of identifications should be factored out of the standard interface. Proposed changes: 1. Replace the first paragraph of Section 2.3.3.5 with the following: "The IdentificationContext object represents the business context in which object identifications apply and the identification formats and rules that apply in that context. For example, an identification context may define Navy part numbers and generate identifications conforming to the formatting and rules that the Navy and the PDM require. Different contexts can be defined for different government agencies, vendors, or even internal divisions." 2. Replace the first line of IDL with the following: typedef string IdentificationContextName; 3. Add the operation CosPropertyService::PropertySet IdentificationContext::get_properties(). 4. Delete the operation IdentificationContextFactory::find_id_contexts. 5. Delete all text between the IDL (starting with "Implementations...") and find. 6. Add the following description of get_properties(): "Returns a PropertySet indicating the names of the properties that are required to generate a valid identifier in the current context. Default values may be supplied for some or all of the properties. The client should fill in the values of the properties and then pass the filled-in PropertySet to generate_id. 7. Append the following text to the description of find_id_context: "The the_context_name parameter specifies the business-related name. If the implementation supports a default identification context or only one identification context, the default name is represented by the empty string (that is, a string of length 0)." 8. In Factory operations, delete the operation find_id_contexts. 9. In Section 2.3.3.6 Design, insert the following text as a new first paragraph: "A context represents a user-level, real-world, business entity. It is entirely separate from any name space hierarchy and/or nomenclature rules that may exist internal to the PDM implementation. Contrariwise, an IdentifierSeq is specifically intended to encapsulate the implementation-dependent aspects of identification and may be used in whatever manner is most convenient to the implementor. An arbitrary number of internal name spaces may be navigated using arbitrarily detailed IdentifierSeqs." Append the following text at the end of what is currently the first paragraph: "...in some way. However, specific interpretations of the content of an IdentifierSeq or identifier string are not within the scope of this standard. For maximum interoperability, a PDM client should treat the IdentifierSeq as an illegible database key and the identifier string as derivative text intended for presentation purposes only." 10. Delete Figure 2-1 and the paragraph that refers to it. 11. Retain Figure 2-2 and the paragraph that refers to it. 12. Delete Figure 2-3 and the remaining two paragraphs leading up to Implementation Issues. 13. In Implementation Issues, insert the following text as a new paragraph between the current first and second paragraphs: "Customizability is also an important product differentiator. Internally, an implementation might support separate name spaces for each descendant of Identifiable. A customer's part numbering system may be different from their document numbering system, and their ECO numbering system will likely be different from those of parts and documents. These are trivially mapped to a single name space per context by using the first component of the IdentifierSeq to select the name space, with the remaining components conforming to the customer-dependent rules for that name space. This enables interoperable clients to achieve a useful level of functionality treating the IdentifierSeq as an illegible database key while customized clients can interpret the contents of the IdentifierSeq according to the needs of each customer." Resolution: Revised Text: Actions taken: January 19, 2001: received issue Discussion: none. The RTF agreed that there is a problem, but could not agree on a solution to it. The problem stated in bullets 1 and 3 is more or less correct - there are two independent ideas here and they have been grouped and objectified, and the current text does not explain/require enough to allow interoperable clients to be constructed. It is also true that this grouping complicates the definition of Bill of Materials queries and simplified traversal operations, features requested in the V2 RFP. The proposed resolution is to remove the second idea - object type as a naming scope - because it is implementation-dependent. And the RTF voted on a proposed text revision to accomplish that resolution, but that proposal did not have majority support. This idea was added to v1.3 in part to reflect the fact that type as a naming scope is a common feature of PDM systems. An alternative proposal to further explain this aspect of the existing IDL was also voted on and failed. Unfortunately, type as a naming scope is a basis for "queries" in many PDM systems as well, and at least one pilot project used this added feature for that purpose. Because a query facility is a required feature of the V2 RFP, it is a concern of some of the RTF members, who are V2 submitters, that this "alternate query facility" should be removed rather than further "enhanced". End of Annotations:===== Date: Fri, 19 Jan 2001 16:52:28 -0500 From: Ed Barkmeyer Reply-To: edbark@cme.nist.gov Organization: NIST X-Sender: "Ed Barkmeyer" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en,fr-FR,de-DE,nl,sv MIME-Version: 1.0 To: issues@omg.org Subject: PDM Enablers issue Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 7o'e9;Yhd9N+D!!o6!e9 Title: IdentificationContext Considered Harmful Source: David Flater, dflater@nist.gov Reference: mfg/2000-07-02, Section 2.3.3.5 and 2.3.3.6. Problem: 1. Confused "context" with "scope" The spec muddles the following two things together: - The need to maintain multiple identifiers for a single entity in different contexts: this Widget is known as Navy Part X, and also as Company Part Y. This is a user-level, real-world, business concept. - The need to qualify the identifiers of different entities based on their scopes: Document X is not the same entity as Part X, and Revision Z of Document X is not the same entity as Revision Z of Document Y. This is an implementation-level concept. Conceptually, the scoping of identifiers occurs within a context, but the spec requires us to create separate IdentificationContexts for every scope. A special case was made to allow Revisions to be implicitly scoped by their Master (Section 2.3.3.6, just above Implementation Issues). This is even worse because it violates the model of identification. An identifier is supposed to uniquely specify an entity within a context. If a Revision cannot be unambiguously retrieved using only a context and an identifier, then Revision should not inherit from Identifiable. If Revisions are identifiable, then their identifications probably consist of a revision number qualified by a path to the Master or by some other information that is sufficient to identify the scope. That is not to say that a user interface would force the user to specify anything more than the revision number once the scope of that session has been established. This is similar to the usage of relative path names in a file system. But in the current spec, a Revision is like some weird, special kind of file that exists within its directory if you go there first but cannot ever be accessed using a fully-qualified path. Consider the ramifications for application programmers. 2. High overhead A consequence of muddling scope with context is the proliferation of IdentificationContexts. A large number of these must be propagated into the Bill of Materials and retrieved and managed by every client program, no matter what the application. This creates special problems for query and traversal convenience functions because there is no convenient way to specify all of the needed IdentificationContexts. Alternately, in the case of implicit scoping, clients are unable to retrieve certain entities based on their identifications alone and must instead navigate from entities whose identifications are unambiguous. The client is forced to manage additional information and perform extra operations because the PDM does not maintain the uniqueness of identifiers. Clients should not be required to navigate to something that is Identifiable; they should be able to do a simple find-by-ID if an ID is what they've got. 3. Interoperable client not feasible A client cannot rely on find_id_context to locate a usable IdentificationContext without special knowledge about the implementation because both the existence of a default context and the set of kinds that have associated IdentificationContexts are implementation-dependent. Instead, an interoperable client must use find_id_contexts to retrieve a list of candidate IdentificationContexts for each interface type and then select among the candidates. The client is trying assemble the collection of IdentificationContexts that would correspond to a single context if scope and context were not intermingled. But since they are, there is no interoperable way to determine which set of IdentificationContexts is appropriate. If the client should luck into an appropriate set of IdentificationContexts, it still must somehow discover and conform to the implementation-dependent rules for the properties to pass to generate_id. There does not seem to be any interoperable way to do this either. 4. Implementation details are exposed The vendor's decision to use a single name space for all PDM objects or to use separate name spaces for every class of objects internal to the PDM is an implementation detail that need not be exposed and should not be exposed. Under the current spec, clients have the unenviable job of discovering and conforming to the internal name space structure of the PDM. They do not really benefit from the standardization of the interface because the behavior is still different for each implementation. Instead, the implementation details of identifications should be factored out of the standard interface. Proposed changes: 1. Replace the first paragraph of Section 2.3.3.5 with the following: "The IdentificationContext object represents the business context in which object identifications apply and the identification formats and rules that apply in that context. For example, an identification context may define Navy part numbers and generate identifications conforming to the formatting and rules that the Navy and the PDM require. Different contexts can be defined for different government agencies, vendors, or even internal divisions." 2. Replace the first line of IDL with the following: typedef string IdentificationContextName; 3. Add the operation CosPropertyService::PropertySet IdentificationContext::get_properties(). 4. Delete the operation IdentificationContextFactory::find_id_contexts. 5. Delete all text between the IDL (starting with "Implementations...") and find. 6. Add the following description of get_properties(): "Returns a PropertySet indicating the names of the properties that are required to generate a valid identifier in the current context. Default values may be supplied for some or all of the properties. The client should fill in the values of the properties and then pass the filled-in PropertySet to generate_id. 7. Append the following text to the description of find_id_context: "The the_context_name parameter specifies the business-related name. If the implementation supports a default identification context or only one identification context, the default name is represented by the empty string (that is, a string of length 0)." 8. In Factory operations, delete the operation find_id_contexts. 9. In Section 2.3.3.6 Design, insert the following text as a new first paragraph: "A context represents a user-level, real-world, business entity. It is entirely separate from any name space hierarchy and/or nomenclature rules that may exist internal to the PDM implementation. Contrariwise, an IdentifierSeq is specifically intended to encapsulate the implementation-dependent aspects of identification and may be used in whatever manner is most convenient to the implementor. An arbitrary number of internal name spaces may be navigated using arbitrarily detailed IdentifierSeqs." Append the following text at the end of what is currently the first paragraph: "...in some way. However, specific interpretations of the content of an IdentifierSeq or identifier string are not within the scope of this standard. For maximum interoperability, a PDM client should treat the IdentifierSeq as an illegible database key and the identifier string as derivative text intended for presentation purposes only." 10. Delete Figure 2-1 and the paragraph that refers to it. 11. Retain Figure 2-2 and the paragraph that refers to it. 12. Delete Figure 2-3 and the remaining two paragraphs leading up to Implementation Issues. 13. In Implementation Issues, insert the following text as a new paragraph between the current first and second paragraphs: "Customizability is also an important product differentiator. Internally, an implementation might support separate name spaces for each descendant of Identifiable. A customer's part numbering system may be different from their document numbering system, and their ECO numbering system will likely be different from those of parts and documents. These are trivially mapped to a single name space per context by using the first component of the IdentifierSeq to select the name space, with the remaining components conforming to the customer-dependent rules for that name space. This enables interoperable clients to achieve a useful level of functionality treating the IdentifierSeq as an illegible database key while customized clients can interpret the contents of the IdentifierSeq according to the needs of each customer." -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Mail Stop 8260 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8260 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority, unless so stated." Date: Tue, 06 Feb 2001 17:15:12 -0500 From: Ed Barkmeyer Reply-To: edbark@cme.nist.gov Organization: NIST X-Sender: "Ed Barkmeyer" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en,fr-FR,de-DE,nl,sv MIME-Version: 1.0 To: PDM RTF Subject: [Fwd: IdentificationContext] Content-Type: multipart/mixed; boundary="------------50B5F66DC59351B9A4E3B716" X-UIDL: `mR!!O/Ce9IU7!!L@@e9 This addresses issue 4161. -------- Original Message -------- Subject: IdentificationContext Date: Tue, 6 Feb 2001 15:42:29 -0500 (EST) From: David Flater To: pete@enabled-systems.com, laemmer@prostep.de,Duane.Silkworth@MetaphaseTech.com CC: Larry.Johnson@mscsoftware.com, edbark@cme.nist.gov Hello, This email message is intended to begin a dialogue on reaching closure on the issue "IdentificationContext Considered Harmful." I have attached the final revision of the issue text resulting from discussions between myself and Ed Barkmeyer. At this time, I consider the following to be the critical points: * In order to avoid a train wreck in the usage of IdContexts for queries and traversals in PDME 2, the "id" field of IdentificationContextNames _must_ be interpreted as a business-related name, and not one that could change with each class of object or other arbitrary scopes within a business-related context. * PDME 1.3 does not enforce this usage, and the latest version of the iViP usage guide in fact recommends a usage that is incompatible with it. * Presently, PDME 2 is using a workaround for id/kind that hinges on the assumption that id is a business-related name. The id/kind approach in PDME 1.3 was inserted in response to the following RTF issue submitted by Duane Silkworth (mfg/00-05-03, May 18 Ballot 2 Draft of the PDM Enablers RTF Final report): 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. My own response would have been in favor of specifying the usage of context names, but reject the part about taking into account the type of the item because the scoping of identifications based on the type of the item is an implementation detail that should be hidden within the identifier instead of exposed through the IdContext interface. The attached proposal involves changing the IDL back so that IdContextNames are once again just strings, effectively only the "id" field. Regards, DWF [] pdme13_idcontexts_considered_harmful_2001-01-12.htm Date: Wed, 07 Feb 2001 12:16:48 +0100 From: Lutz Ldmmer X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Cc: PDM RTF Subject: Re: [Fwd: IdentificationContext] References: <3A807770.55421DE3@nist.gov> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 35h!!OX3!!+J[d9n15e9 Hi all, Furthermore, to open the discussion: A question to the initial authors of the PDMEv1.0: Why was the COS NameService mechanism not adopted in the first place - other parts of the spec do use COSes to some extend 8-). NamingService::NameContext allows all sorts of desirable structuring and browsing of identifiers. An implementation may even impose additional cardinality constraints, like the PDME do - e.g. to bind an object only once to a context. Furthermore, it looks to me attractive, to resolve the problem of revision/iteration identifier scoping by using NameContext hierarchies. Not provided is a method to retrieve all bindings for a given object. Remark: Please note the new version of COS NamingService (ptc/00-08-07) addresses the transformation of NameComponent-sequences to Strings and vice versa. Regards, Ed Barkmeyer wrote: > > This addresses issue 4161. > > -------- Original Message -------- > Subject: IdentificationContext > Date: Tue, 6 Feb 2001 15:42:29 -0500 (EST) > From: David Flater > To: pete@enabled-systems.com, laemmer@prostep.de,Duane.Silkworth@MetaphaseTech.com > CC: Larry.Johnson@mscsoftware.com, edbark@cme.nist.gov > > Hello, > > This email message is intended to begin a dialogue on reaching closure > on the issue "IdentificationContext Considered Harmful." > > I have attached the final revision of the issue text resulting from > discussions between myself and Ed Barkmeyer. > > At this time, I consider the following to be the critical points: > > * In order to avoid a train wreck in the usage of IdContexts for > queries and traversals in PDME 2, the "id" field of > IdentificationContextNames _must_ be interpreted as a business-related > name, and not one that could change with each class of object or > other arbitrary scopes within a business-related context. > > * PDME 1.3 does not enforce this usage, and the latest version of > the iViP usage guide in fact recommends a usage that is > incompatible with it. > > * Presently, PDME 2 is using a workaround for id/kind that hinges > on the assumption that id is a business-related name. > > The id/kind approach in PDME 1.3 was inserted in response to the > following RTF issue submitted by Duane Silkworth (mfg/00-05-03, May 18 > Ballot 2 Draft of the PDM Enablers RTF Final report): > > 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. > > My own response would have been in favor of specifying the usage of > context names, but reject the part about taking into account the type > of the item because the scoping of identifications based on the type > of the item is an implementation detail that should be hidden within > the identifier instead of exposed through the IdContext interface. > > The attached proposal involves changing the IDL back so that > IdContextNames are once again just strings, effectively only the "id" > field. > > Regards, > DWF > > ------------------------------------------------------------------------ > Name: pdme13_idcontexts_considered_harmful_2001-01-12.htm > pdme13_idcontexts_considered_harmful_2001-01-12.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 -- ___________________________________________________________ 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 ___________________________________________________________ Date: Wed, 07 Feb 2001 11:09:22 -0500 From: "Manfred R. Koethe" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Lutz Ldmmer CC: PDM RTF Subject: Re: [Fwd: IdentificationContext] References: <3A807770.55421DE3@nist.gov> <3A812EA0.AC2CA002@prostep.de> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 5TZ!!REPe9P^_!!Z8dd9 Lutz, It was a pure oversight not to use the Naming Service mechanism in the original JPDM (PDME 1.0) submission. And with a specification as large and complex as the PDME, you find some pottholes only when you start implementing it. Therefore the attempt of correction in 1.3. I agree with you that the INS (Interoperable Naming Service) offers the right service model to be used in the identifaction / identification context area of PDME. I was arguing for this already in the 1.3 RTF discussions. Kind regards, Manfred Lutz Ldmmer wrote: > Hi all, > > Furthermore, to open the discussion: > A question to the initial authors of the PDMEv1.0: > Why was the COS NameService mechanism not adopted in the first place >- > other parts of the spec do use COSes to some extend 8-). > NamingService::NameContext > allows all sorts of desirable structuring and browsing of >identifiers. > An implementation may even impose additional cardinality >constraints, > like > the PDME do - e.g. to bind an object only once to a context. > Furthermore, > it looks to me attractive, to resolve the problem of >revision/iteration > identifier scoping by using NameContext hierarchies. Not provided is >a > method > to retrieve all bindings for a given object. > > Remark: > Please note the new version of COS NamingService (ptc/00-08-07) > addresses the transformation of NameComponent-sequences to > Strings and vice versa. > > Regards, > > Ed Barkmeyer wrote: > > > > This addresses issue 4161. > > > > -------- Original Message -------- > > Subject: IdentificationContext > > Date: Tue, 6 Feb 2001 15:42:29 -0500 (EST) > > From: David Flater > > To: pete@enabled-systems.com, >laemmer@prostep.de,Duane.Silkworth@MetaphaseTech.com > > CC: Larry.Johnson@mscsoftware.com, edbark@cme.nist.gov > > > > Hello, > > > > This email message is intended to begin a dialogue on reaching >closure > > on the issue "IdentificationContext Considered Harmful." > > > > I have attached the final revision of the issue text resulting >from > > discussions between myself and Ed Barkmeyer. > > > > At this time, I consider the following to be the critical points: > > > > * In order to avoid a train wreck in the usage of IdContexts >for > > queries and traversals in PDME 2, the "id" field of > > IdentificationContextNames _must_ be interpreted as a >business-related > > name, and not one that could change with each class of object >or > > other arbitrary scopes within a business-related context. > > > > * PDME 1.3 does not enforce this usage, and the latest version >of > > the iViP usage guide in fact recommends a usage that is > > incompatible with it. > > > > * Presently, PDME 2 is using a workaround for id/kind that >hinges > > on the assumption that id is a business-related name. > > > > The id/kind approach in PDME 1.3 was inserted in response to the > > following RTF issue submitted by Duane Silkworth (mfg/00-05-03, >May 18 > > Ballot 2 Draft of the PDM Enablers RTF Final report): > > > > 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. > > > > My own response would have been in favor of specifying the usage >of > > context names, but reject the part about taking into account the >type > > of the item because the scoping of identifications based on the >type > > of the item is an implementation detail that should be hidden >within > > the identifier instead of exposed through the IdContext interface. > > > > The attached proposal involves changing the IDL back so that > > IdContextNames are once again just strings, effectively only the >"id" > > field. > > > > Regards, > > DWF > > > > >------------------------------------------------------------------------ > > Name: >pdme13_idcontexts_considered_harmful_2001-01-12.htm > > pdme13_idcontexts_considered_harmful_2001-01-12.htm Type: >Hypertext Markup Language (text/html) > > Encoding: >base64 > > -- > ___________________________________________________________ > > 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 > ___________________________________________________________ -- ___________________ / Manfred R. Koethe \____________________________________________ IONA Technologies, Inc. Phone: +[1](781)902-8557 200 West Street Fax: +[1](781)902-8001 Waltham, MA 02451, USA E-Mail: manfred.koethe@iona.com From: David Flater MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: <14978.45522.512880.722872@mouse.msid.cme.nist.gov> Date: Thu, 8 Feb 2001 09:48:50 -0500 (EST) To: "Manfred R. Koethe" Cc: Lutz Ldmmer , PDM RTF Subject: Re: [Fwd: IdentificationContext] In-Reply-To: <3A817332.A03F176D@iona.com> References: <3A807770.55421DE3@nist.gov> <3A812EA0.AC2CA002@prostep.de> <3A817332.A03F176D@iona.com> 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: !YBe9N1jd9a4]!!)^Ae9 At this point, is there a proposal to remodel the Identification interfaces using the INS, either in the 1.4 RTF or starting in V2? I don't want to defeat the purpose by pushing too hard, but I am afraid that this issue will just fall on the floor again if I don't make enough noise. We need to reach closure for the sake of PDME 2.0. Regards, DWF Manfred R. Koethe writes: > I agree with you that the INS (Interoperable Naming Service) offers > the right service model to be used in the identifaction / identification > context area of PDME. I was arguing for this already in the 1.3 RTF > discussions. Date: Thu, 15 Mar 2001 12:09:10 +0100 From: Lutz Ldmmer X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Cc: PDM RTF Subject: Draft resolution of PDM RTF issue 4161 References: <3AAEA522.A638485D@nist.gov> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 'C~e9Yp7!!TH2!!jKEe9 Hi, the infamous issue 4161 call for resolution and I drafted the proposal following the least change approach sticking with the ([scope, context], id) formulation as: =============================== Resolution: Accepted in principle The concerns are valid, but the existing implementation may serve the requested functionality. The changes made in V1.3 need more explanation. Extra text of clarification is added. Revised Text: edit directions against formal/00-11-11: page 3-9, first paragraph replace "multiple types of Identifiable objects." by "support multiple derived types of Identifiable objects with a common supertype." page 3-10, extend description of method IdentificationContextFactory::find_id_context Returns the IdentificationContext instance with the context name specified. The given context name must match both in the id and the kind fields. page 3-10, extend description of method IdentificationContextFactory::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. If the request queries for an IdentificationContext for a derived type and the server provides IdentificationContexts for supertypes of that type only, than the most specialized IdentificationContexts are returned. If the request queries for an IdentificationContext for a supertype and the server provides IdentificationContexts for some or all of its derived types, than all of them are returned. Therefore, it is not guaranteed, that the server provides a suitable IdentificationContext to narrow the query based on Identifiable to a specified Identifiable type. ================================ 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 ___________________________________________________________ From: David Flater MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: <15030.19090.103828.44974@mouse.msid.cme.nist.gov> Date: Mon, 19 Mar 2001 13:06:10 -0500 (EST) To: Lutz Ldmmer Cc: PDM RTF Subject: Re: Draft resolution of PDM RTF issue 4161 In-Reply-To: <3AB0A2D6.51D0F401@prostep.de> References: <3AAEA522.A638485D@nist.gov> <3AB0A2D6.51D0F401@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: PD\!!+0Me9VdM!!g~$e9 Lutz =?iso-8859-1?Q?L=E4mmer?= writes: > Hi, > > the infamous issue 4161 call for resolution and I drafted the proposal > following the > least change approach sticking with the ([scope, context], id) Hi, FYI, an update on my deliverable -- I still have not received specific feedback from Manfred, so as of now, my original proposal stands unchanged. DWF From: David Flater MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: <15035.32366.466294.292707@mouse.msid.cme.nist.gov> Date: Fri, 23 Mar 2001 11:48:46 -0500 (EST) To: pdm-rtf@omg.org Subject: Draft resolution of PDM RTF issue 4161 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: `T+e9!MN!!~amd9X1ad9 $Id: pdme13_idcontexts_considered_harmful_proposal.txt,v 1.7 2001/03/23 16:47:56 dflater Exp $ Following is my draft resolution of issue 4161 to change back to the (context, id) approach. I regret that I have not been able to obtain any additional feedback from Manfred since the meeting, so I have not made any IDL changes. The following change text differs from that contained in the "IdContext Considered Harmful" HTML of 2001-01-12 in the following ways: - Flattened to ASCII - Added resolution verbiage. - Harmonized description of get_properties with the similar PDME2 operation PdmServer::get_properties. (This clarifies the usage with respect to mandatory, optional, and defaulted properties.) Resolution: Accepted. Though it was not documented in the RTF report, the changes made in PDME 1.3 were inspired by an attempt to use the IdentificationContext::find operation to support queries of the form "Select * from Items where Item_type = 'FooDocument' and Item_number = 'XYZ';" However, that was not the intent of the IdentificationContext::find operation. Moreover, the changes made in 1.3 were broken by committee revisions and did not serve their intended goal. The original intention was to do something like define the usage of the first element of the IdentifierSeq with respect to Item_type, or package Item_type with IdentifierSeq in a struct. Considering that query operations that will obsolete any such usage of IdentificationContext::find have already been defined for the next version of the PDME standard, to make either of those changes now would just create an unwanted backwards compliance point. Not using the applicable Name Service model for hierarchically structured identification contexts has been acknowledged as an oversight, but it would be too disruptive to attempt to define how that would work now. Revised text: Edit directions against mfg/2000-07-02: Replace the first paragraph of Section 2.3.3.5 with the following: "The IdentificationContext object represents the business context in which object identifications apply and the identification formats and rules that apply in that context. For example, an identification context may define Navy part numbers and generate identifications conforming to the formatting and rules that the Navy and the PDM require. Different contexts can be defined for different government agencies, vendors, or even internal divisions." Replace the first line of IDL with the following: typedef string IdentificationContextName; Add the operation CosPropertyService::PropertySet IdentificationContext::get_properties(). Delete the operation IdentificationContextFactory::find_id_contexts. Delete all text between the IDL (starting with "Implementations...") and find. Add the following description of get_properties(): "Returns a PropertySet indicating the properties that can be passed to generate_id to generate a valid identifier in the current context. All properties understood by the PdmSystem for this context will be included in the returned properties. Some of the properties may be filled in with default values while others will be returned as "nil". The client must, at a minimum, supply values for those properties that are nil. The implication is that any property that is optional shall be defaulted (with, perhaps, a null string, for instance)." Append the following text to the description of find_id_context: "The the_context_name parameter specifies the business-related name. If the implementation supports a default identification context or only one identification context, the default name is represented by the empty string (that is, a string of length 0)." In Factory operations, delete the operation find_id_contexts. In Section 2.3.3.6 Design, insert the following text as a new first paragraph: "A context represents a user-level, real-world, business entity. It is entirely separate from any name space hierarchy and/or nomenclature rules that may exist internal to the PDM implementation. Contrariwise, an IdentifierSeq is specifically intended to encapsulate the implementation-dependent aspects of identification and may be used in whatever manner is most convenient to the implementor. An arbitrary number of internal name spaces may be navigated using arbitrarily detailed IdentifierSeqs." Append the following text at the end of what is currently the first paragraph: "...in some way. However, specific interpretations of the content of an IdentifierSeq or identifier string are not within the scope of this standard. For maximum interoperability, a PDM client should treat the IdentifierSeq as an illegible database key and the identifier string as derivative text intended for presentation purposes only." Delete Figure 2-1 and the paragraph that refers to it. Retain Figure 2-2 and the paragraph that refers to it. Delete Figure 2-3 and the remaining two paragraphs leading up to Implementation Issues. In Implementation Issues, insert the following text as a new paragraph between the current first and second paragraphs: "Customizability is also an important product differentiator. Internally, an implementation might support separate name spaces for each descendant of Identifiable. A customer's part numbering system may be different from their document numbering system, and their ECO numbering system will likely be different from those of parts and documents. These are trivially mapped to a single name space per context by using the first component of the IdentifierSeq to select the name space, with the remaining components conforming to the customer-dependent rules for that name space. This enables interoperable clients to achieve a useful level of functionality treating the IdentifierSeq as an illegible database key while customized clients can interpret the contents of the IdentifierSeq according to the needs of each customer."