Issue 1540: ModelElement needs to have permanent, unique, unchanging, identifier (mof-rtf) Source: (, ) Nature: Revision Severity: Significant Summary: Summary: ModelElement needs to have a permanent, unique, unchanging, non-redundant (within the transitive closure of a "large" namespace) (meta)identifier in addition to or as a replacement for qualifiedName as a local (meta)attribute. Resolution: Revised Text: Actions taken: June 24, 1998: received issue May 8, 2000: closed issue August 30, 2000: reopened Discussion: This means that a model element in a metamodel will be identified by an id that will not change from one release to another if a concept does not change (even if the name of one of the enclosing packages chages)and the id will change if the meaning changes (e.g a local meta attribute is deleted or gets a new data type, a local meta-relationship is deleted), even if the name does not change. Discussion (crawley@dstc.edu.au): I agree that there is a need for something like this. For example, without it, it is hard to implement a reliable, efficient caching mechanisms. [This is biting me at the moment ...] However, I think that such a facility needs to apply to all MOF meta-models not just to the MOF meta-meta-model. Assuming this is so, the correct place to put such functionality is in Reflective::RefObject or maybe Reflective::RefBaseObject. We also need to precisely specify the domain(s) of the identifiers uniqueness, and/or decide what should not be specified: • Temporal: should identifiers last forever, or can the be recycled i.e. used on a new object? If an object that has been deleted is "returned from the dead" (e.g. restored from a backup) should it have its original identifier or a new one? • Logical: should the domain in which object identifiers are required to be unique be a) the "package instance", b) the "repository", c) the MOF server, d) a federation of MOF servers, e) all MOF servers, or f) something else. • Physical: should logical copies of the same meta-object have different identifiers? I'm particularly concerned that any identifier scheme works (has acceptable semantics, and has a reasonable implemention without "magic") in centralized, federated and discon-nected meta-data repository scenarios. I think this presupposes an analysis of the requirements; i.e. what do people want to be able to use these identifiers for? Discussion (Sridhar.Iyengar2@unisys.com): Agree that the identity solution needs to apply to all MOF compliant meta models and that the Reflective interfaces are an appropriate mechanism to expose these interfaces In general - I think reusing Ids (from dead objects) is a problematic one. In general copies should have their own identity, with potentially optional associations to 'originator' Logical - I need think this thru - Feel it should at least be a federation of MOF servers. I dont know any easy way of enforcing 'all MOF servers' Discussion (crawley@dstc.edu.au): I discussed this further with various people around the time of the Seattle meeting, and came to the conclusion that different people have up to three (and maybe more) kinds of unique identifiers in mind: 1. Identifiers that can be compared to test for object identity of (mutable) MOF meta-objects. 2. Identifiers that can be compared to test for value equivalence of (immutable) MOF meta-objects. 3. Identifiers that can be compared to test if two distinct meta-objects denote "corre-sponding" meta-objects in a model / meta-model, where details of the concept's rep-resentations may differ. For example, they might be used to relate objects that "correspond" after a round-trip model exchange, or objects in different models that denote the same "concept". Of these, we can currently only implement the first kind of identifier. The other two require additional mechanisms that the MOF does not currently provide. Proposed resolution: 1. Add a new operation to RefBaseObject to return a meta-object's identifier. 2. Define the external representation of identifiers as based on human readable strings, using a prefix to distinguish formats. 3. Require identifiers to be unique in time across all domains with actual or possible connectivity. Suggest DCE UUIDs as the preferred identifier mechanism. 4. Define binding between object and identifier as being one-to-one and immutable through the lifetime of the object. In other words, no reuse of identifiers after object deletion, and no changing of an object's identifier while the object exists ... in any form. 5. State that a MOF implementation is non-compliant if its identifiers are locally unique but are non-unique in the context of actual interoperation. Ditto for a MOF implementation that does not implement binding rules in the context of actual inter-operation. 6. Rule other kinds of unique identifier out of scope for the MOF RTF. Implementation: Added a description of the mof_id operation to Section 6.2.2, “Re-flective:: RefBaseObject,” on page 6-5 with the description of it be-ing unique and immutable. Also added the mof_id operation to the IDL in Section 6.2.2, “Reflective::RefBaseObject,” on page 6-5 and Appendix B.2 “MOF IDL Summary”. [KR] Implementation: Added text on semantics, including text on ensuring uniqueness and on conformance to Section 6.2.2, “Reflective::RefBaseObject,” on page 6-5. [SC] Implementation: Removed the Section "Requirements to Support Object Identity" from Appendix “MOF Implementation Requirements” as there now is a system of MOF object identification. Done. [KR] This issue was closed following MOF RTF 1.3. However, an AB member (Jeff Mishinsky?) suggested that the RTF ought to standardise a preferred format for MOF id strings, rather than just describing the properties that MOF ids must have. End of Annotations:===== Return-Path: Date: Tue, 23 Jun 1998 20:14:58 -0400 From: www To: juergen@omg.org, web-incoming@omg.org Subject: WWW Form output Name: Woody Pidcock Company: Boeing Email: woody.pidcock@boeing.com Notification: Yes Specification: MOF Specification Section: 3.7.1 Formal #: ad/97-08-14 Version: Revision_Date: Page: 3-13 Nature: Revision Severity: Significant full_desc: ModelElement needs to have a permanent, unique, unchanging, non-redundant (within the transitive closure of a "large" namespace) (meta)identifier in addition to or as a replacement for qualifiedName as a local (meta)attribute. This means that a model element in a metamodel will be identified by an id that will not change from one release to another if a concept does not change (even if the name of one of the enclosing packages chages)and the id will change if the meaning changes (e.g a local meta attribute is deleted or gets a new data type, a local meta-relationship is deleted), even if the name does not change. submit: Submit Issue Report Return-Path: To: mof-rtf@omg.org Subject: Re: Issue 1540: unique identifiers Date: Wed, 15 Jul 1998 12:59:53 +1000 From: Stephen Crawley Woody Pidcock suggests: > > ModelElement needs to have a permanent, unique, unchanging, > non-redundant > (within the transitive closure of a "large" namespace) > (meta)identifier > in addition to or as a replacement for qualifiedName as a local > (meta)attribute. I agree that there is a need for something like this. For example, without it, it is hard to implement a reliable, efficient caching mechanisms. [This is biting me at the moment ...] However, I think that such a facility needs to apply to all MOF meta-models not just to the MOF meta-meta-model. Assuming this is so, the correct place to put such functionality is in Reflective::RefObject or maybe Reflective::RefBaseObject. We also need to precisely specify the domain(s) of the identifiers uniqueness, and/or decide what should not be specified: 1) Temporal: should identifiers last forever, or can the be recycled i.e. used on a new object? If an object that has been deleted is "returned from the dead" (e.g. restored from a backup) should it have its original identifier or a new one? 2) Logical: should the domain in which object identifiers are required to be unique be: a) the "package instance", b) the "repository", c) the MOF server, d) a federation of MOF servers, e) all MOF servers, or f) something else. 3) Physical: should logical copies of the same meta-object have different identifiers? I'm particularly concerned that any identifier scheme works (has acceptable semantics, and has a reasonable implemention without "magic") in centralized, federated and disconnected meta-data repository scenarios. I think this presupposes an analysis of the requirements; i.e. what do people want to be able to use these identifiers for? -- Steve Return-Path: From: "Iyengar, Sridhar" To: mof-rtf@omg.org, Stephen Crawley Subject: RE: Issue 1540: unique identifiers Date: Wed, 15 Jul 1998 07:26:04 -0500 Agree that the identity solution needs to apply to all MOF compliant meta models and that the Reflective interfaces are an appropriate mechanism to expose these interfaces In general - I think reusing Ids (from dead objects) is a problematic one. In general copies should have their own identity, with potentially optional associations to 'originator' Logical - I need think this thru - Feel it should at least be a federation of MOF servers. I dont know any easy way of enforcing 'all MOF servers' Sridhar ------------------------------------------------------------------------ --------------------------------------------- Sridhar Iyengar Unisys Fellow sridhar.iyengar@mv.unisys.com Unisys Corporation 714-380-5692 (Pho) 25725, Jeronimo Rd 714-380-6632 (Fax) Mission Viejo, CA 92691 656-5692 (Net) ------------------------------------------------------------------------ ---------------------------------------------- > ---------- > From: Stephen Crawley[SMTP:crawley@dstc.edu.au] > Sent: Tuesday, July 14, 1998 7:59 PM > To: mof-rtf@omg.org > Subject: Re: Issue 1540: unique identifiers > > > Woody Pidcock suggests: > > > > ModelElement needs to have a permanent, unique, unchanging, > non-redundant > > (within the transitive closure of a "large" namespace) > (meta)identifier > > in addition to or as a replacement for qualifiedName as a local > > (meta)attribute. > > I agree that there is a need for something like this. For example, > without it, it is hard to implement a reliable, efficient caching > mechanisms. > [This is biting me at the moment ...] > > However, I think that such a facility needs to apply to all MOF > meta-models > not just to the MOF meta-meta-model. Assuming this is so, the > correct > place to put such functionality is in Reflective::RefObject or maybe > Reflective::RefBaseObject. > > We also need to precisely specify the domain(s) of the identifiers > uniqueness, and/or decide what should not be specified: > > 1) Temporal: should identifiers last forever, or can the be > recycled > i.e. used on a new object? If an object that has been deleted > is > "returned from the dead" (e.g. restored from a backup) should > it > have its original identifier or a new one? > > 2) Logical: should the domain in which object identifiers are > required to be unique be: a) the "package instance", b) the > "repository", c) the MOF server, d) a federation of MOF > servers, e) all MOF servers, or f) something else. > > 3) Physical: should logical copies of the same meta-object have > different identifiers? > > I'm particularly concerned that any identifier scheme works (has > acceptable semantics, and has a reasonable implemention without > "magic") > in centralized, federated and disconnected meta-data repository > scenarios. > > I think this presupposes an analysis of the requirements; i.e. what > do people want to be able to use these identifiers for? > > -- Steve > > Return-Path: Date: Thu, 30 Jul 1998 07:03:32 -0700 From: GK Khalsa Organization: Object Radiance, Inc. To: "mof-rtf@omg.org" Subject: Discussion of Issue 1540 Discussion of Issue 1540: ModelElement needs to have permanent, unique, unchanging, identifier Most of this solution is available in the MOF now. The fully qualified name (provided by ModelElement) provides a name which is unique within a metamodel. The MOF has suggested (but not required) metamodel naming based on internet domain names -- a "global registry" solution that does not require the definition and maintenance of a new global registry. The elements required are: (1) the means of naming metamodels and accessing the name; and (2) a versioning scheme. The solution to the first is not difficult. In the current practice of allowing multiple top-level packages to define a metamodel, the metamodel name must be provided by the ModelRepository, which should be available via the repository_container() operation of every model element. A worthwhile solution to versioning will require some effort, but will be essential to the evolution of metamodels. -- GK Khalsa khalsa@objectrad.com Object Radiance, Inc. v: +1 909 677 2518 Murrieta, CA USA f: +1 909 677 1478 Return-Path: To: GK Khalsa cc: "mof-rtf@omg.org" , crawley@dstc.edu.au Subject: Re: Discussion of Issue 1540 Date: Fri, 31 Jul 1998 16:34:10 +1000 From: Stephen Crawley GK, You wrote: > Most of this solution is available in the MOF now. The fully > qualified name (provided by ModelElement) provides a name > which is unique within a metamodel. The MOF has suggested > (but not required) metamodel naming based on internet domain > names -- a "global registry" solution that does not require > the definition and maintenance of a new global registry. The > elements required are: (1) the means of naming metamodels > and accessing the name; and (2) a versioning scheme. Your proposal does not solve the problem. What you have missed is that the unique identifier needs to be unchanging and unchangeable. In addition, it must work for all models as well as for meta-models. A unique identifier based on model element names fails because names are in general changeable. This is certainly true in the case of Model::ModelElement::name. It also fails because in general, meta-models are not required to provide names for elements, let alone locally unique ones. Furthermore, a unique identifier that depends on the context of an object breaks if it is possible to change the context of the object. Your 'global registry' names have this property. I can definitely change an object's container, and (maybe) I can change the name of a repository or (maybe) move a 'model' into a different repository. A unique identifier that may change without the identity of the object changing is no good for the kinds of purposes that I and (I think) Woody envisage. -- Steve Return-Path: From: "Khalsa, GK" To: mof-rtf@omg.org Subject: Re: Discussion of Issue 1540 (more) Date: Mon, 3 Aug 1998 10:48:45 -0700 > GK, > You wrote: > > Most of this solution is available in the MOF now. The fully > > qualified name (provided by ModelElement) provides a name > > which is unique within a metamodel. The MOF has suggested > > (but not required) metamodel naming based on internet domain > > names -- a "global registry" solution that does not require > > the definition and maintenance of a new global registry. The > > elements required are: (1) the means of naming metamodels > > and accessing the name; and (2) a versioning scheme. > Your proposal does not solve the problem. > What you have missed is that the unique identifier needs to > be unchanging and unchangeable. In addition, it must work for > all models as well as for meta-models. Woody's original issue was identification of metamodel elements, not model elements. I don't think the MOF can, or should provide a single solution for all Models. > A unique identifier based on model element names fails because names > are in general changeable. This is certainly true in the case > of Model::ModelElement::name. It also fails because in general, > meta-models are not required to provide names for elements, let > alone locally unique ones. All elements of a metamodel do have unique names (within their namespace), as required by the MOF. We already state that a model element name may not be changed, once the metamodel is published. Until this time (when the metamodel is under development), there is no concern about globally unique identifiers. > Furthermore, a unique identifier that depends on the context > of an object breaks if it is possible to change the context of > the object. Your 'global registry' names have this property. > I can definitely change an object's container, and (maybe) I can > change the name of a repository or (maybe) move a 'model' into a > different repository. None of these actions can be performed on a published metamodel. What we need to do is devise a versioning approach that does not break these current constraints. The required restriction would be that a subsequent version of an element cannot change its name or its container. That is, if a Class is moved to another Package, it is no longer a new version of an existing class, but a new Class (and a new version of both Packages). Likewise for renaming. > A unique identifier that may change without the identity of the > object changing is no good for the kinds of purposes that I > and (I think) Woody envisage. I believe the problem Woody wants to solve (and that XMI needs to address) involves unambiguous identification of metamodel elements for published metamodels. This issue can be kept separate from CORBA's difficult object identity issue or any OIDs that may support the caching, persistence, etc, of implementations.