Issue 2923: mof rtf issue - setting UUIDs (mof-rtf) Source: International Business Machines (Dr. Stephen Brodsky, Ph.D, sbrodsky(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: The MOF interfaces need to provide an API to set uuids. A convention for denoting uuids for metamodel objects defined by OMG standards would be beneficial. For example, the uuids of the UML Class, Attribute, and Operation constructs could be set following this convention by the UML RTF. Resolution: Revised Text: Actions taken: September 22, 1999: received issue Discussion: End of Annotations:===== From: sbrodsky@us.ibm.com X-Lotus-FromDomain: IBMUS To: mof-rtf@omg.org, issues@omg.org Message-ID: <872567F4.0045A1F1.00@d53mta04h.boulder.ibm.com> Date: Wed, 22 Sep 1999 05:25:58 -0700 Subject: mof rtf issue - setting UUIDs Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 7d62b6d9236c2d285d418e0f5739e142 Dear MOF RTF, The MOF interfaces need to provide an API to set uuids. A convention for denoting uuids for metamodel objects defined by OMG standards would be beneficial. For example, the uuids of the UML Class, Attribute, and Operation constructs could be set following this convention by the UML RTF. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 X-Mailer: exmh version 2.0.2 2/24/98 To: sbrodsky@us.ibm.com cc: mof-rtf@omg.org, issues@omg.org, crawley@dstc.edu.au Subject: Re: mof rtf issue - setting UUIDs In-reply-to: Your message of "Wed, 22 Sep 1999 05:25:58 MST." <872567F4.0045A1F1.00@d53mta04h.boulder.ibm.com> Mime-Version: 1.0 Date: Thu, 23 Sep 1999 11:06:28 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: +)9!!Z`$"!/i,e9Yf9!! Steve, On the face of it, this sounds a reasonable request. However, providing an API which allowed the user to change a MOF meta-objects UUID has some potentially disaterous consequences. The MOF spec is written on the assumption that the binding between a MOF UUID and a MOF meta-object is unchangeable. If we start to allow it to be changed then: 1) Client applications that assume the binding is unchangeable are potentially broken. 2) The carefully designed rules for uniqueness checking in Associations Attributes and Parameters fall apart. I see the problem you are trying to solve here. How is it possible to create a meta-object (e.g. from an XMI stream) that has the same UUID as an equivalent meta-object in another MOF (or non-MOF) repository? I can think of a couple of answers that don't involve destroying the MOF's semantic foundation ... 1) A MOF's repository's XMI consumer does not necessarily need to use the CORBA APIs to create the meta-objects. For example, if the repository and consumer code are co-located, the latter can use native calls to do the job. [OK ... it is bad form to invoke "magic" in a OMG standard ... but in reality products may be implemented this way anyhow ...] 2) It should be possible to let a MOF client (e.g. an external XMI stream consumer) supply UUIDs when it creates meta-objects. This could be done by adding a new UUID parameter to the "create_" operation ... or by providing an new "recreate_" operation or the like. 3) Alternatively, caller supplied UUIDs could be implemented without changing the existing APIs by a using callback mechanism; i.e. i) client registers a UUID supplier callback ii) client calls "create_" iii) server calls back to client passing the new meta-object and requesting a UUID iv) client callback returns UUID v) server sets UUID and returns completed meta-object to client vi) repeat steps ii) through v) ad nauseum. Note that if the client does not want to supply UUIDs it need not register a callback, and steps iii) and iv) wouldn't occur. All in all, I think I prefer adding a "recreate_" operations. It makes the generated interfaces bigger, but hey, memory is cheap :-) -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Mime-Version: 1.0 Date: Sat, 23 Jun 2001 01:46:11 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: bd4!!i/,e9F6$e9^*=e9 This issue calls for an API that allows a client to set the identifier returned by Reflective::RefBaseObject::refMofId(). The mofId property is used to test for meta-object identity in the context of the IDL mapping. The proposal being developed for data typing in MOF 1.4 assumes that we can determine that copy of the PrimitiveTypes package that is uploaded via XMI (say) is the same logical meta-object as a local copy. If we continue to use mofIds to denote meta-object identity, it would seem that an XMI consumer would need to be able to set the mofId of each newly created instance to a value passed in the XMI document. This means we need to resolve this issue in this RTF, not put it off. However, given that MOF's equality semantics are (in the IDL mapping at least) dependent on the value returned by refMofId(), we cannot let this value be changed willy-nilly. In particular, 1) no two distinct meta-objects should have the mofId value, and 2) no meta-object should have its mofId value changed after a client has called refMifId() on the object. Two distinct meta-objects with the same mofId value is a recipe for disaster. If the meta-objects are not logically equal (e.g. isomorphic), this is clearly wrong. Even if they are logically equal but physically distinct, there is a risk that something may change one meta-object and not the other. One problem with allowing a a meta-object's mofId to change after some client has retrieved it is that introduces potential race conditions when comparing meta-objects. There are possibly others too. So ... here's an initial proposal for the mofId setting API. First, add the following operation to Reflective::RefObject: void refSetMofId(in string new_id) raises (MofError); The 'refSetMofId' operation can only be invoked on a RefObject which is an instance of a Class in a meta-model; i.e. it can't be used on a Class proxy object ... or on an Association object or Package object. Throw MofError("WrongScope") in this case [or define a new kind?] If 'refSetMofId' is invoked on an instance whose mofId has been published, throw MofError("NotChangeable") [or define a new king?] If 'refSetMofId' is invoked with a mofId that is already associated with another known meta-object, throw MofError("MofIdInUse") [new]. The implementation is required to check AT LEAST the outermost package extent for the object for other uses of the mofId value. Otherwise, 'refSetMofId' will change the pseudo-attribute to the new value; i.e. so that an immediately following call to refMofId() will return the new. In addition, add the following operation to RefPackage. This will inevitably be needed by XMI consumers. When refSetMofId throws MofError("MofIdInUse"), the next thing a consumer will need to do is find the existing instance with the given mofId. RefBaseObject resolveMofId(in string mof_id) raises (NotFound); The 'resolveMofId' operation uses a mofId as a key to lookup a meta-object. If the mofId is unknown, NotFound is thrown. An implementation must be capable of looking up AT LEAST extant meta-objects (of all flavours) in the outermost package extent. It must also be able to lookup any other meta-object for which 'refSetMofId' throws MofError("MofIdInUse"). [Must be capable in the absence of failures, etc ...] What have I missed this time? -- Steve From: "Pete Rivett" To: "'Stephen Crawley'" , Subject: RE: Issue 2923: mof rtf issue - setting UUIDs Date: Sun, 24 Jun 2001 11:57:34 +0100 Message-ID: <000601c0fd4e$cf9d41c0$0100007f@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: <200106221545.f5MFjv610785@piglet.dstc.edu.au> Content-Type: text/plain; charset="us-ascii" X-UIDL: aK+e9PKUd96# -----Original Message----- > From: Stephen Crawley [mailto:crawley@dstc.edu.au] > Sent: 22 June 2001 16:46 > To: mof-rtf@omg.org > Subject: Re: Issue 2923: mof rtf issue - setting UUIDs > > > This issue calls for an API that allows a client to set the identifier > returned by Reflective::RefBaseObject::refMofId(). The mofId property > is used to test for meta-object identity in the context of > the IDL mapping. > > The proposal being developed for data typing in MOF 1.4 > assumes that we > can determine that copy of the PrimitiveTypes package that is uploaded > via XMI (say) is the same logical meta-object as a local copy. If we > continue to use mofIds to denote meta-object identity, it would seem > that an XMI consumer would need to be able to set the mofId of each > newly created instance to a value passed in the XMI document. This > means we need to resolve this issue in this RTF, not put it off. > > However, given that MOF's equality semantics are (in the IDL > mapping at > least) dependent on the value returned by refMofId(), we cannot let > this value be changed willy-nilly. In particular, > > 1) no two distinct meta-objects should have the mofId value, and > > 2) no meta-object should have its mofId value changed after a > client has called refMifId() on the object. > > Two distinct meta-objects with the same mofId value is a recipe for > disaster. If the meta-objects are not logically equal (e.g. > isomorphic), > this is clearly wrong. Even if they are logically equal but > physically > distinct, there is a risk that something may change one meta-object > and not the other. > > One problem with allowing a a meta-object's mofId to change after some > client has retrieved it is that introduces potential race conditions > when comparing meta-objects. There are possibly others too. > > So ... here's an initial proposal for the mofId setting API. > > First, add the following operation to Reflective::RefObject: > > void refSetMofId(in string new_id) raises (MofError); > > The 'refSetMofId' operation can only be invoked on a RefObject which > is an instance of a Class in a meta-model; i.e. it can't be used on a > Class proxy object ... or on an Association object or Package object. > Throw MofError("WrongScope") in this case [or define a new kind?] > > If 'refSetMofId' is invoked on an instance whose mofId has been > published, throw MofError("NotChangeable") [or define a new king?] > > If 'refSetMofId' is invoked with a mofId that is already associated > with another known meta-object, throw MofError("MofIdInUse") [new]. > The implementation is required to check AT LEAST the outermost > package extent for the object for other uses of the mofId value. > > Otherwise, 'refSetMofId' will change the pseudo-attribute to the > new value; i.e. so that an immediately following call to refMofId() > will return the new. > > In addition, add the following operation to RefPackage. This will > inevitably be needed by XMI consumers. When refSetMofId throws > MofError("MofIdInUse"), the next thing a consumer will need to do > is find the existing instance with the given mofId. > > RefBaseObject resolveMofId(in string mof_id) raises (NotFound); > > The 'resolveMofId' operation uses a mofId as a key to lookup a > meta-object. If the mofId is unknown, NotFound is thrown. An > implementation must be capable of looking up AT LEAST extant > meta-objects (of all flavours) in the outermost package extent. > It must also be able to lookup any other meta-object for which > 'refSetMofId' throws MofError("MofIdInUse"). [Must be capable > in the absence of failures, etc ...] > > What have I missed this time? > > -- Steve > > > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Mime-Version: 1.0 Date: Thu, 28 Jun 2001 15:46:20 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: @A!!!g"j!!nCZ!!/`[d9 Here's the formal proposed resolution for this issue ... > Source: International Business Machines (Dr. Stephen Brodsky, Ph.D, > sbrodsky@us.ibm.com) > Nature: Uncategorized Issue > Severity: > Summary: The MOF interfaces need to provide an API to set uuids. A > convention > for denoting uuids for metamodel objects defined by OMG standards > would be > beneficial. For example, the uuids of the UML Class, Attribute, and > Operation > constructs could be set following this convention by the UML RTF. Proposed Resolution: Add two new operations to the Reflective IDL, one to set the mofId value for a RefObject, and the other to lookup an RefBaseObject using its mofId. These operations are constrained to 1) minimise anomalies resulting from mofIds changing, and 2) make the operations implementable. Proposed Revised Text: In section 6.1 change: "* test for MOF object identity, and" to "* manage MOF meta-object identifiers and use them to test meta-object identity, and " In section 6.2.2, change the 'isQuery' specification for 'refModId' to: isQuery: no In section 6.2.2, change the first two paragraphs of description for 'refMofId' to read as follows: "Every MOF object has a permanent, unique MOF identifier associated with it. A default value for an object's MOF identifier is generated when the object is created. The value of an object's identifier becomes permanently bound to the object when one of the following events occurs: * a client invokes the 'refMofId()' operation to obtain the object's MOF identifier, * the object is returned as the result of a client call to the 'RefPackage::refResolveMofId()' operation, or * a client calls the 'RefObject::refSetModId()' operation to supply a MOF identifier value for the object. The 'refSetMofId' operation can only be called for a MOF 'instance' object, and only if the object's MOF identifier is not already permanently bound. Once an object's identifier is bound, it must change for the remainder of the lifetime of the object. The primary purpose of MOF identifiers is to allow clients to definitively establish a MOF object's identity. Indeed, a MOF object's bound MOF identifier denotes the object's identity. A MOF implementation must ensure that no two distinct MOF objects within the extent of a given outermost Package object ever have the same MOF identifier. This invariant must hold for the lifetime of the extent." In section 6.2.3 insert the following before refIsInstanceOf. "refSetModId The "refSetModId" operation allows the client to provide a non-default MOF identifier for a MOF instance object. If the operation succeeds, it has the side-effect of permanently binding the instances MOF identifier. specific analog: none return type: none isQuery: no parameters: mofId : in String exceptions: MofError(MofIdInUse, NotChangeable, WrongScope) If the target object is a class proxy object rather than an instance object, MofError(WrongScope) is thrown. If the target object's MOF identifier is already permanently bound, MofError(NotChangeable) is thrown. If the supplied 'mofId' is known to be bound to some other extant object, or to have previously been bound to some deleted object, MofError(MofIdInUse) is thrown. Note - an implementation of this operation must at least reject attempts to set the target object's MOF identifier to be the same as the MOF identifier for some other object in the target's outermost package extent." In the Interface subsection of 6.2.3 insert this IDL operation as the first operation: void ref_set_mof_id(in string mof_id) raises (MofError); In section 6.2.5 insert the following before refClassRef. "refResolveMofId The "refResolveMofId" operation looks up the RefBaseObject that has a given MOF identifier. specific analog: none return type: RefBaseObject isQuery: yes parameters: mofId : in String exceptions: MofError(UnknownMofId, InvalidObject) If the MOF identifier is unknown, MofError(UnknownMofId) is thrown. If the MOF identifier is for an object that is known to have previously existed, MofError(InvalidObject) is thrown. An implementation must be capable of looking up AT LEAST all extant MOF objects (of all kinds) defined in the outermost package extent. It must also be able to lookup any other meta-object for which 'RefObject::refSetMofId' throws MofError(MofIdInUse). " In the Interface subsection of 6.2.5 insert this IDL operation as the first operation: RefBaseObject ref_resolve_mof_id(in string mof_id) raises (MofError); In section 5.4.6, add the following to the table of Reflective Errors. "Mof Id In Use A nil object reference none "Mof Id In Use" arises when "refSetMofId" detects that the supplied MOF identifier is the identifier for some other extant or deleted MOF object. Unknown Mof Id A nil object reference none "Unknown Mof Id" arises when "refResolveMofId" is called with a MOF identifier that is not known." In section 5.4.6, change the entry for "Wrong Scope" in the table of Reflective Errors to read: "Wrong Scope Attribute or Operation used, or a nil object reference\ none "Wrong Scope" arises when an attempt is made to use an instance-level Attribute or Operation from a Class proxy object. It also arises if 'refSefMofId' is called on a Class proxy object." In section 5.4.6 add the following at the end of the IDL after the table: const string MOF_ID_IN_USE_VIOLATION = "org.omg.mof:reflective.mof_id_in_use"; const string UNKNOWN_MOF_ID = "org.omg.mof:reflective.unknown_mof_id"; Make all of the above IDL changes to Appendix B.2. From: "Martin Matula" To: , "Stephen Crawley" References: <200106280546.f5S5k4620183@piglet.dstc.edu.au> Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Date: Thu, 28 Jun 2001 10:00:38 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: lN;e9!e$e9R/3!!:i%e9 Hi, something is not clear to me regarding this issue. It is common in our MOF repository to have 2 instances of MOF model and load the same metamodel (let's say UML) into each of them. Now isn't it strange to have two object with the same MOF ID (e.g. UmlClass) returning different results from some operations (e.g. outermost package, immediate package, possibly also meta object)? Isn't this unacceptable? Martin ----- Original Message ----- From: "Stephen Crawley" To: Sent: Thursday, June 28, 2001 7:46 AM Subject: Re: Issue 2923: mof rtf issue - setting UUIDs > > Here's the formal proposed resolution for this issue ... > > > Source: International Business Machines (Dr. Stephen Brodsky, >Ph.D, > > sbrodsky@us.ibm.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: The MOF interfaces need to provide an API to set uuids. A convention > > for denoting uuids for metamodel objects defined by OMG standards >would be > > beneficial. For example, the uuids of the UML Class, Attribute, >and Operation > > constructs could be set following this convention by the UML RTF. > > Proposed Resolution: > > Add two new operations to the Reflective IDL, one to set the mofId >value > for a RefObject, and the other to lookup an RefBaseObject using its >mofId. > These operations are constrained to 1) minimise anomalies resulting >from > mofIds changing, and 2) make the operations implementable. > > Proposed Revised Text: > > In section 6.1 change: > > "* test for MOF object identity, and" > > to > > "* manage MOF meta-object identifiers and use them to test > meta-object identity, and " > > > In section 6.2.2, change the 'isQuery' specification for 'refModId' >to: > > isQuery: no > > > In section 6.2.2, change the first two paragraphs of description for > 'refMofId' to read as follows: > > "Every MOF object has a permanent, unique MOF identifier >associated with > it. A default value for an object's MOF identifier is generated >when > the object is created. The value of an object's identifier >becomes > permanently bound to the object when one of the following events occurs: > > * a client invokes the 'refMofId()' operation to obtain the > object's MOF identifier, > > * the object is returned as the result of a client call to the > 'RefPackage::refResolveMofId()' operation, or > > * a client calls the 'RefObject::refSetModId()' operation to >supply > a MOF identifier value for the object. > > The 'refSetMofId' operation can only be called for a MOF >'instance' > object, and only if the object's MOF identifier is not already > permanently bound. Once an object's identifier is bound, it must > change for the remainder of the lifetime of the object. > > The primary purpose of MOF identifiers is to allow clients to > definitively establish a MOF object's identity. Indeed, a > MOF object's bound MOF identifier denotes the object's identity. > A MOF implementation must ensure that no two distinct MOF objects > within the extent of a given outermost Package object ever have > the same MOF identifier. This invariant must hold for the >lifetime > of the extent." > > > In section 6.2.3 insert the following before refIsInstanceOf. > > "refSetModId > > The "refSetModId" operation allows the client to provide a >non-default > MOF identifier for a MOF instance object. If the operation >succeeds, > it has the side-effect of permanently binding the instances MOF identifier. > > specific analog: none > return type: none > isQuery: no > parameters: mofId : in String > exceptions: MofError(MofIdInUse, NotChangeable, WrongScope) > > If the target object is a class proxy object rather than an >instance > object, MofError(WrongScope) is thrown. If the target object's >MOF > identifier is already permanently bound, MofError(NotChangeable) >is > thrown. If the supplied 'mofId' is known to be bound to some >other > extant object, or to have previously been bound to some deleted >object, > MofError(MofIdInUse) is thrown. > > Note - an implementation of this operation must at least reject > attempts to set the target object's MOF identifier to be the same > as the MOF identifier for some other object in the target's > outermost package extent." > > > In the Interface subsection of 6.2.3 insert this IDL operation as > the first operation: > > void ref_set_mof_id(in string mof_id) > raises (MofError); > > > In section 6.2.5 insert the following before refClassRef. > > "refResolveMofId > > The "refResolveMofId" operation looks up the RefBaseObject that > has a given MOF identifier. > > specific analog: none > return type: RefBaseObject > isQuery: yes > parameters: mofId : in String > exceptions: MofError(UnknownMofId, InvalidObject) > > If the MOF identifier is unknown, MofError(UnknownMofId) is >thrown. > If the MOF identifier is for an object that is known to have > previously existed, MofError(InvalidObject) is thrown. > > An implementation must be capable of looking up AT LEAST all >extant > MOF objects (of all kinds) defined in the outermost package >extent. > It must also be able to lookup any other meta-object for which > 'RefObject::refSetMofId' throws MofError(MofIdInUse). " > > > In the Interface subsection of 6.2.5 insert this IDL operation as > the first operation: > > RefBaseObject ref_resolve_mof_id(in string mof_id) > raises (MofError); > > > In section 5.4.6, add the following to the table of Reflective >Errors. > > "Mof Id In Use > A nil object reference > none > "Mof Id In Use" arises when "refSetMofId" detects that the > supplied MOF identifier is the identifier for some > other extant or deleted MOF object. > > Unknown Mof Id > A nil object reference > none > "Unknown Mof Id" arises when "refResolveMofId" is called > with a MOF identifier that is not known." > > > In section 5.4.6, change the entry for "Wrong Scope" in the table of > Reflective Errors to read: > > "Wrong Scope > Attribute or Operation used, or a nil object reference\ > none > "Wrong Scope" arises when an attempt is made to use an > instance-level Attribute or Operation from a > Class proxy object. It also arises if 'refSefMofId' > is called on a Class proxy object." > > > In section 5.4.6 add the following at the end of the IDL after the >table: > > const string MOF_ID_IN_USE_VIOLATION = > "org.omg.mof:reflective.mof_id_in_use"; > const string UNKNOWN_MOF_ID = > "org.omg.mof:reflective.unknown_mof_id"; > > > Make all of the above IDL changes to Appendix B.2. > > > > > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin Matula" cc: mof-rtf@omg.org, "Stephen Crawley" , crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from "Martin Matula" > of "Thu, 28 Jun 2001 10:00:38 +0200." ><02a601c0ffa8$6b422720$844b9c81@matula> Mime-Version: 1.0 Date: Thu, 28 Jun 2001 23:04:23 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 >(http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: j6U!!UU0e9C$:!!pd7!! Martin, martin.matula@czech.sun.com said: > something is not clear to me regarding this issue. It is common in our > MOF repository to have 2 instances of MOF model and load the same > metamodel (let's say UML) into each of them. Now isn't it strange to > have two object with the same MOF ID (e.g. UmlClass) returning > different results from some operations (e.g. outermost package, > immediate package, possibly also meta object)? Isn't this > unacceptable? This behaviour in a MOF / IDL repository is not conformant to MOF 1.3 and would not be conformant to MOF 1.4 (assuming my proposed resolution is accepted). In both versions of the spec, it is clearly and explicitly stated that no two MOF objects in the same package extent may have the same MOF identifier. Furthermore, they both state that any federation of MOF servers in which this invariant does not hold is non-conformant. The reason for this is that equality of MOF objects is DEFINED to be based on comparison of the objects' MOF identifier values. If two distinct MOF objects have the same MOF identifier, the semantics of composition, sets and associations can go completely haywire. So if you are saying that this is how your MOF 1.3 or MOF 1.4 server currently works, then your server is not MOF compliant. However, if you are talking about an implementation of JMI, the MOF spec says nothing about MOF identifiers in this context. (Strictly speaking, the MOF 1.3 and 1.4 specs only define MOF identifiers in the context of the IDL mapping.) However, I'd be worried if the JMI spec did allow two or more JMI objects to share the JMI equivalent of the MOF identifier. -- Steve From: "Martin Matula" To: "Stephen Crawley" Cc: , "Stephen Crawley" References: <200106281304.f5SD4N423696@piglet.dstc.edu.au> Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Date: Thu, 28 Jun 2001 18:25:19 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 'm7e9##2!!UDWd9J4Qd9 Steve, I am not sure you understand what my point was. Currently, none of two different objects have the same MOF ID in our repository. The MOF IDs are generated implicitly when an object is created. So I wouldn't say that our repository is not MOF compliant. However, if we would implement your proposal, we may get into trouble: I don't think it is illegal (I don't see, which sentence in MOF spec. would forbid it) to connect client to two distinct MOF repositories. If I would do so, and had the same model loaded in both repositories, using your proposal, I could achieve, that in each of these two repositories are objects with the same ID (e.g. if a UmlClass will specify its UUID explicitly, then each repository that will load model of UML will contain UmlClass - instance of MOF class - with this specific MOF ID), however, as MOF ID for package proxies will be generated independently in each of these two repositories, client code comparing UmlClass from repository 1 will say that it is equal to UmlClass from repository 2, but UmlClass from repository 1 will return different package proxy as its outermost or immediate package than the UmlClass from repository 2. This looks weird to me, so my question is, whether this is how it should work... If not, then how do you want to solve this problem? Martin ----- Original Message ----- From: "Stephen Crawley" To: "Martin Matula" Cc: ; "Stephen Crawley" ; Sent: Thursday, June 28, 2001 3:04 PM Subject: Re: Issue 2923: mof rtf issue - setting UUIDs > > Martin, > > martin.matula@czech.sun.com said: > > something is not clear to me regarding this issue. It is common in >our > > MOF repository to have 2 instances of MOF model and load the same > > metamodel (let's say UML) into each of them. Now isn't it strange >to > > have two object with the same MOF ID (e.g. UmlClass) returning > > different results from some operations (e.g. outermost package, > > immediate package, possibly also meta object)? Isn't this > > unacceptable? > > This behaviour in a MOF / IDL repository is not conformant to MOF >1.3 > and would not be conformant to MOF 1.4 (assuming my proposed >resolution > is accepted). > > In both versions of the spec, it is clearly and explicitly stated >that > no two MOF objects in the same package extent may have the same MOF > identifier. Furthermore, they both state that any federation of > MOF servers in which this invariant does not hold is non-conformant. > > The reason for this is that equality of MOF objects is DEFINED to be > based on comparison of the objects' MOF identifier values. If two > distinct MOF objects have the same MOF identifier, the semantics of > composition, sets and associations can go completely haywire. > > So if you are saying that this is how your MOF 1.3 or MOF 1.4 server > currently works, then your server is not MOF compliant. However, if >you > are talking about an implementation of JMI, the MOF spec says >nothing > about MOF identifiers in this context. (Strictly speaking, the MOF >1.3 > and 1.4 specs only define MOF identifiers in the context of the IDL > mapping.) However, I'd be worried if the JMI spec did allow two or >more > JMI objects to share the JMI equivalent of the MOF identifier. > > -- Steve > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: David Mellor , "Baisley, Donald E" , "Martin Matula" Cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from "Martin Matula" of "Thu, 28 Jun 2001 18:25:19 +0200." <043501c0ffee$ec91c790$844b9c81@matula> Mime-Version: 1.0 Date: Fri, 29 Jun 2001 12:29:43 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: F&L!!hmMe9EPAe9/"gd9 David, Martin and Don, Martin Matula and Dave Mellor have raised some problems with the proposed UUID reolution that need to be thought and talked through. We four have an action to reach a conclusion on this by next Tuesday US time. In this email, I'm just restating the problems as precisely as I can. My thoughts on them will be in a followup ... The problem Martin raised is as follows. Assume that we have two servers for (say) the MOF::Model interfaces, which manage two separate MOF::Model package extents. Assume that these servers have no "magic" (i.e. beyond the scope of the MOF 1.4 spec) way of coordinating MOF identifier usage. Consider the following: 1) A meta-model is entered into the first repository; e.g. using a design tool. 2) The meta-model is exported as an XMI file, putting the MOF Identifiers into the XMI file as UUIDs. 3) The XMI file is imported into the second repository, using an import tool that sets the respective MOF identifiers according to the UUIDs in the XMI file. 4) Some client tool then tries to use objects from both repositories, and finds two distinct copies of some model element with the same MOF identifier. Whoops! The problem that David raised is as follows. Assume that we have one server for (say) the MOF::Model interfaces. Consider the following: 1) A meta-model is entered into the repository using some design tool. 2) Various other stuff is developed using the MOF objects; e.g. other meta-models import the meta-model, the meta-model is "instantiated" as a repository, etc. 3) In the process of 2), the default MOF identifiers for the meta-model MOF objects are used and get bound. 4) The meta-modeller realizes that he / she should have used specific MOF identifiers for the meta-object. Whoops! The MOF identifiers are bound and can't be changed. In fact, the design tool is most likely to cause the default MOF identifiers to be bound. This may well happen while the meta-modeller is entering the meta-model elements ... and BEFORE he/she specifies the MOF identifiers to be used. [It would be hard to implement a design tool / compiler that didn't do this ...] -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: David Mellor , "Baisley, Donald E" , "Martin Matula" , crawley@dstc.edu.au Cc: mof-rtf@omg.org Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from Stephen Crawley of "Fri, 29 Jun 2001 12:29:43 +1000." <200106290229.f5T2Th427315@piglet.dstc.edu.au> Mime-Version: 1.0 Date: Fri, 29 Jun 2001 16:12:49 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: multipart/mixed ; boundary="==_Exmh_-3148864500" X-UIDL: 4-id9>Tc!!FOP!!j*"e9 David, Martin and Don, My initial response to Martin's problem was going to be "Your not supposed to do that". But after some more thought, that's beside the point. The point is that Martin's scenario is reasonable, and the MOF ought to be able to cope with it. But I can't see how we can do this without addressing the Federation issue more broadly. For now, I think we just have to say that if a client is going to be able to access two repositories, the repositories need to be connected in some unspecified (magic) way so that they can maintain the invariant that no two MOF objects have the same MOF identifier. If we back away from solving the "set UUID" problem now, we'll have to rework the 2198 resolution. 2198 depends on being able to test the identity of the PrimitiveTypes package, etc, and that is only practical if XMI consumers can set UUIDs. In the long term, I think we are going to have to rethink the way that we handle MOF object identity. This is a HARD problem, and I don't think we can address it before our deadline, -- Steve Content-Type: message/rfc822 ; name="1264" Content-Description: 1264 Content-Disposition: attachment; filename="1264" Return-Path: crawley@dstc.edu.au Delivery-Date: Fri, 29 Jun 2001 12:29:46 +1000 Received: from dstc.edu.au (soluble.dstc.edu.au [130.102.176.43]) by piglet.dstc.edu.au (8.11.3/8.11.3) with ESMTP id f5T2Th427315; Fri, 29 Jun 2001 12:29:43 +1000 (EST) Message-Id: <200106290229.f5T2Th427315@piglet.dstc.edu.au> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: David Mellor , "Baisley, Donald E" , "Martin Matula" Cc: mof-rtf@omg.org, crawley Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from "Martin Matula" of "Thu, 28 Jun 2001 18:25:19 +0200." <043501c0ffee$ec91c790$844b9c81@matula> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Jun 2001 12:29:43 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) David, Martin and Don, Martin Matula and Dave Mellor have raised some problems with the proposed UUID reolution that need to be thought and talked through. We four have an action to reach a conclusion on this by next Tuesday US time. In this email, I'm just restating the problems as precisely as I can. My thoughts on them will be in a followup ... The problem Martin raised is as follows. Assume that we have two servers for (say) the MOF::Model interfaces, which manage two separate MOF::Model package extents. Assume that these servers have no "magic" (i.e. beyond the scope of the MOF 1.4 spec) way of coordinating MOF identifier usage. Consider the following: 1) A meta-model is entered into the first repository; e.g. using a design tool. 2) The meta-model is exported as an XMI file, putting the MOF Identifiers into the XMI file as UUIDs. 3) The XMI file is imported into the second repository, using an import tool that sets the respective MOF identifiers according to the UUIDs in the XMI file. 4) Some client tool then tries to use objects from both repositories, and finds two distinct copies of some model element with the same MOF identifier. Whoops! The problem that David raised is as follows. Assume that we have one server for (say) the MOF::Model interfaces. Consider the following: 1) A meta-model is entered into the repository using some design tool. 2) Various other stuff is developed using the MOF objects; e.g. other meta-models import the meta-model, the meta-model is "instantiated" as a repository, etc. 3) In the process of 2), the default MOF identifiers for the meta-model MOF objects are used and get bound. 4) The meta-modeller realizes that he / she should have used specific MOF identifiers for the meta-object. Whoops! The MOF identifiers are bound and can't be changed. In fact, the design tool is most likely to cause the default MOF identifiers to be bound. This may well happen while the meta-modeller is entering the meta-model elements ... and BEFORE he/she specifies the MOF identifiers to be used. [It would be hard to implement a design tool / compiler that didn't do this ...] -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Stephen Crawley cc: David Mellor , "Baisley, Donald E" , "Martin Matula" , mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from Stephen Crawley of "Fri, 29 Jun 2001 12:29:43 +1000." <200106290229.f5T2Th427315@piglet.dstc.edu.au> Mime-Version: 1.0 Date: Fri, 29 Jun 2001 16:31:30 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: multipart/mixed ; boundary="==_Exmh_-2614340860" X-UIDL: +JY!!XGSd9gk8!!UZFe9 David, Martin and Don, David's problem is a serious one. Now that I think of it, it could be pretty difficult to construct (particularly) graphical meta-data input tools that allowed the user to use a specific MOF identifier for some MOF object. And there are also cases where tools have a legitimate need to change MOF identifiers. I think we've therefore got to relax the rules about changing "bound" identifiers. But the spec must (obviously) include a strong warning about the potential consequences of changing a MOF identifier that some other tool might already know about. Once again, the long term solution probably entails use some other mechanism for denoting / testing MOF object equality ... in the context of Federation and other things. -- Steve Return-Path: crawley@dstc.edu.au Delivery-Date: Fri, 29 Jun 2001 12:29:46 +1000 Received: from dstc.edu.au (soluble.dstc.edu.au [130.102.176.43]) by piglet.dstc.edu.au (8.11.3/8.11.3) with ESMTP id f5T2Th427315; Fri, 29 Jun 2001 12:29:43 +1000 (EST) Message-Id: <200106290229.f5T2Th427315@piglet.dstc.edu.au> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: David Mellor , "Baisley, Donald E" , "Martin Matula" Cc: mof-rtf@omg.org, crawley Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from "Martin Matula" of "Thu, 28 Jun 2001 18:25:19 +0200." <043501c0ffee$ec91c790$844b9c81@matula> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Jun 2001 12:29:43 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) [] 1264 From: "Martin Matula" To: "Stephen Crawley" Cc: "David Mellor" , "Baisley, Donald E" , References: <200106290631.f5T6VU423918@piglet.dstc.edu.au> Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Date: Fri, 29 Jun 2001 11:23:38 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Y;Yd9[24e9]i To: "Stephen Crawley" Cc: "David Mellor" ; "Baisley, Donald E" ; "Martin Matula" ; ; Sent: Friday, June 29, 2001 8:31 AM Subject: Re: Issue 2923: mof rtf issue - setting UUIDs > David, Martin and Don, > > David's problem is a serious one. Now that I think of it, it could >be > pretty difficult to construct (particularly) graphical meta-data >input > tools that allowed the user to use a specific MOF identifier for >some > MOF object. And there are also cases where tools have a legitimate > need to change MOF identifiers. > > I think we've therefore got to relax the rules about changing >"bound" > identifiers. But the spec must (obviously) include a strong warning > about the potential consequences of changing a MOF identifier that > some other tool might already know about. > > Once again, the long term solution probably entails use some other > mechanism for denoting / testing MOF object equality ... in the > context of Federation and other things. > > -- Steve > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin Matula" cc: "Stephen Crawley" , "David Mellor" , "Baisley, Donald E" , mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from "Martin Matula" of "Fri, 29 Jun 2001 11:23:38 +0200." <05ec01c1007d$2f935020$844b9c81@matula> Mime-Version: 1.0 Date: Mon, 02 Jul 2001 10:54:57 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: 8(]!!8d+!!)6$!!UZXd9 > I think that the current proposal brings more and bigger problems than it > solves. I am against providing API for changing MOF IDs from the first > moment. It is without doubt a tricky problem. And what we are proposing clearly doe not work well in "federated" configurations ... like the one you are describing. However, we have a REAL problem here. Saying a solution is bad is not helpful ... unless you have a better alternative to propose. > I don't think it is a good idea, and I am also not sure that this > was what Don was proposing when he was talking about providing a URI > for > some elements - that was my feeling from his e-mails sent to the > mailing > list (I admit I didn't attend the telecon, where you were discussing > this > issue so that's why I am maybe missing something). You are missing something. Don was talking about using standard URIs to denote identity of key standardised objects. He was clearly NOT talking about using URIs as (technology neutral) MOF object references. That would be a very bad idea because: * it would require a bunch of extra stuff to standardise mapping of URIs to viable object references in various technologies, * it assumes (for the references to be usable) that the receiver can talk to the sender's repository. > I think that MOF ID > shouldn't have any special meaning - it should be generated - and > should be > used only for identification of objects (you can understand it as an > "address" of the element - if you do identity checking in C++ by > comparing > addresses of two objects, you also would not want to change address > of some > special objects to some special value - it is just a random number > used for > object identification). Ideally yes. In practice, we ALSO have the problem of how to say that two physical objects in different repositories represent the same logical MOF object. > I would be glad if we could find some other way of searching for objects. > Cannot we add another attribute (e.g. called UUID), which could be optional > (for some elements it can have empty string value) and the elements that > will specify a value of this UUID, will be searchable by some method in > RefPackage? [The key problem is not searching. The key problem is object identity. The requirement for searching on MOF Identifier is a consequence of being able to set a MOF object's MOF identifier ... ] > This UUID attribute would be changeable. MOF IDs would remain generated. > The UUID value (if it is specified) should be unique in the package extent. > Other approach could be to have the UUID derived from UUID of model (AFAIK > each standard metamodel has UUID) and fully qualified name of an element. > Then we wouldn't need any new UUID attribute. I don't see how this solves the problem arising from the resolution to 2198. > // This would be the most natural solution I > // think - you wouldn't need those constraints > // that only RefObjects can have MOF ID > // specified explicitly, etc. What is the set of > // object we need the UUID for?? It is any > // subset of all instances of MOF element. But > // this is exactly the same set for which the fully > // qualified name is applicable... > If the XMI would be loaded, all the references to other objects > using their > UUIDs will be resolved during the XMI loading. When the XMI will be > generated, UUIDs will be computed from the model and written to the > XMI. > MOF ID should still be used for identity checking. If I define a new pseudo-attribute for all MOF instance objects, how does it relate to testing MOF object identity? If there is no connection, what is the point of the UUID? If the UUID is the identity marker, how have I solved the problem of two distinct objects having the same "identity"? Frankly, to the degree that I understand Martin's proposal above, I don't think it helps. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin Matula" , "David Mellor" , "Baisley, Donald E" , mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from Stephen Crawley of "Mon, 02 Jul 2001 10:54:57 +1000." <200107020054.f620su429573@piglet.dstc.edu.au> Mime-Version: 1.0 Date: Mon, 02 Jul 2001 11:49:07 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: khMe9L&&!!S*$e9!]jd9 Folks, I think I may have a "solution" to the problem of setting MOF Identifiers in a loosely federated environment; i.e. one in which repositories have no knowledge of each other's MOF Identifier <-> object mappings. The problem with having two physically distinct MOF (instance) objects with the same MOF Identifier is that they might end up with different state. If we could ensure (to a reasonable degree of confidence) that this didn't happen, then there wouldn't be a problem ... I claim. In certain circumstances, I think we can do this. One way to ensure two copies of an object mean the same thing is to get them into the same state then irrevocably disable any further updates. If we combine this with MOF's current use of MOF identifiers to denote identity, we get a consistent picture of the two objects meaning the same thing. Here's how we could apply this to the MOF -> XMI -> MOF scenario: * Define a pervasive notion of a frozen MOF object; i.e. an object for which no further updates can occur. * When producing an XMI document, record in the document which MOF instance objects are frozen. * When consuming an XMI document, do the following: + If the XMI encoded object is not frozen, create a MOF object in the repository with a new MOF identifier. + If the XMI encoded object is frozen, the consumer can EITHER create a new (frozen or unfrozen) object with a new MOF Identifier OR create a frozen object with the same MOF Identifier as the original MOF object. This assumes that nothing can change the state of a frozen object, and that the state doesn't get changed in transit; e.g. in the XMI doecument. But assuming that, we have an approach for replicating standard (frozen) metadata, Here is how we could we realise this in the IDL Mapping. 1) Codify the semantics of "freezing". It should prevent all changes to an instance's attribute values and any "hidden state", but I think we shouldn't freeze links 2) Change the refSetMofId() operation so that it freezes the object as a side-effect. 3) Add another operation (say) refFreezeObject() that allows (at least) any 'instance' object to be frozen. The MOF Model currently has an underspecified notion that a model element may be in a "frozen" state that disables any further changes to its state. There is currently an operation (on Model::ModelElement) to test to see if a ModelElement is "frozen", and the behaviour of a "frozen" but there is currently no API to freeze elements. There is an existing MOF RTF issue (2182) to complete / extend freezing. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: David Mellor , "Baisley, Donald E" , "Martin Matula" , "Dirckze, Ravi" Cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from Stephen Crawley of "Fri, 29 Jun 2001 16:31:30 +1000." <200106290631.f5T6VU423918@piglet.dstc.edu.au> Mime-Version: 1.0 Date: Mon, 02 Jul 2001 12:23:13 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: ecDe9SC"!!o,Yd9Y6Qe9 Martin, Dave and Don / Ravi, Here are what I think our options on UUIDs are: 1) Proceed to vote on the 2923 resolution as previously drafted ... with the problem of federation left for a future RTF. 2) Develop (IN SHORT ORDER) a concrete resolution 2182 that solves the problem. Then do 2923 and 2182 vote. 3) Withdraw 2923 again and don't address it. This leaves us with a big hole in the 2198 resolution, so: a) Leave the hole; i.e. provide no standard APIs that would allow you to deserialise PrimitiveTypes with the correct MOF Identifier. [Implementors could hack together a proprietary solution ...] b) Change the 2198 resolution so that representation of standard primitive types does NOT rely on MOF object identity. c) Withdraw the 2198 resolution. In my view, 3c is not an option. The resolution to 2198 has passed, and there would be HUGE resistance to reversing it. Forget it. Option 3b is politically tricky. Don / Ravi will have to change their positions on this ... and then we'll need to re-vote 2198. Option 3a leaves a significant hole in the spec. Option 2 is risky. I'm not sure we can get our heads around this approach in time. Option 1 also leaves a significant hole in the spec. But at least we could argue that MOF 1.3 federation is an unsolved problem anyway. IMO, option 3b is the technically best solution in the short term and option 2 in the long term (e.g. for MOF 1.5). Option 1 is better than Option 3a ... but both are nasty. -- Steve From: "Martin Matula" To: "Stephen Crawley" Cc: "David Mellor" , "Baisley, Donald E" , References: <200107020054.f620su429573@piglet.dstc.edu.au> Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Date: Mon, 2 Jul 2001 11:15:55 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: (2_d9,E$!!L],!!LBUd9 Hi Steve, > However, we have a REAL problem here. Saying a solution is bad is not > helpful ... unless you have a better alternative to propose. I think that the alternative I gave was better. E.g. in COM, each component has its own UUID. However, it is not necessarily true, that all objects with the same UUID are the same. You can have different version of a component using the same UUID - the new version of component is a different object however, it has the same UUID. The key thing is that both versions with the same UUID encapsulate exactly the same functionality (same interface, etc.) - only implementation can be different. I think in our case we also don't need a solution, which would rely on exact identity of objects. What we are looking for is a new kind of equivalence, which will tell us, that no matter which object I will choose from this equivalence class (each equivalence divides set of elements to several classes - classes consist of elements which are equal in sense of this equivalence), it will satisfy my needs. I think that the UUID (composed of UUID of metamodel and fully qualified name of element) I was describing in my previous mail does this. I am saying that for purposes of resolution to 2198 it is enough to find a correct primitive type using this special UUID. I don't see why we should require that any two object with the same UUID should have also same MOF ID - it is clear that any two object with the same UUID are logically the same (they don't need to be the same physical identities). If we will accept this (I don't see why we shouldn't), I don't see any holes in spec. and any need to deal with federations. > > I think that MOF ID > > shouldn't have any special meaning - it should be generated - and > > should be > > used only for identification of objects (you can understand it as > > an > > "address" of the element - if you do identity checking in C++ by comparing > > addresses of two objects, you also would not want to change > > address of some > > special objects to some special value - it is just a random number > > used for > > object identification). > > Ideally yes. In practice, we ALSO have the problem of how to say > > that > two physical objects in different repositories represent the same > > logical > MOF object. I think that the UUID described in my previous mail and used in the text above gives a perfect way of saying that two physical objects in different repositories represent the same logical MOF object (if they have the same UUID, they represent the same logical object). I think it is clear that we have several identities here - logical and physical. Physical identitiy is described by MOF ID. What we need to find is a way of describing logical identity - I think what you are trying to do is to mix these two. No wonder, that it doesn't work well... > If I define a new pseudo-attribute for all MOF instance objects, how does > it relate to testing MOF object identity? If there is no connection, what > is the point of the UUID? If the UUID is the identity marker, how have > I solved the problem of two distinct objects having the same "identity"? As I said IMO we have to kinds of equivalences here. The first of them (I would call it physical) is determined by MOF ID and in sense of this equivalence two objects are equal <=> their MOF IDs are equal. The equivalence that we currently need is the one that says that 2 objects are equal <=> they represent the same logical element in the same model. I think that this equivalence can be easily determined by the UUID I have described. Hopefuly I have clarified more what I was meaning. Regards, Martin X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin Matula" cc: "Stephen Crawley" , "David Mellor" , "Baisley, Donald E" , mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from "Martin Matula" of "Mon, 02 Jul 2001 11:15:55 +0200." <09de01c102d7$9a27fa60$844b9c81@matula> Mime-Version: 1.0 Date: Tue, 03 Jul 2001 01:18:06 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: #fMe9>=7e9R% To: "Stephen Crawley" Cc: "David Mellor" , "Baisley, Donald E" , References: <200107021518.f62FI4401178@piglet.dstc.edu.au> Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Date: Mon, 2 Jul 2001 18:05:36 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: *Tm!!Qol!!iA>e92@D!! Hi Steve, > Question 1: Is the new UUID you are proposing a real attribute like > 'name' on ModelElement, or a pseudo-attribute like the current MOF > Id > returned by refMofId()? The UUID I was thinking about was simply UUID of metamodel + fully qualified name of element - we may or may not provide a getter for it. As I wrote before, it would be applicable only for instances of MOF elements. > Question 2: Does anything in your proposal prevent two objects with > different state (e.g. attribute values) from having the same UUID? No. > Question 3: Does anything in your proposal prevent two objects in > the same repository from having the same UUID? Yes - MOF constraint which says that name of each element has to be unique within an extended namespace. > Question 4: What is the relationship between equivalence based on > MOF Identifiers and equivalence based on your UUIDs? I think that for one metamodel, you can have many physical representations of it in form of repository objects. Metamodel loaded into repository A is one representation and the same metamodel loaded into repository B is the second representation of the same thing. Equivalence based on my UUIDs would tell you, whether two objects (which may have different MOF IDs) are representation of the same metamodel element. Equivalence based on MOF IDs would tell you, whether the two object references point to the same representation of some metamodel element. > Question 5: What version of equivalence is used to determine if two > MOF instances are the same for the purposes of Set membership, Link > checking, etc? MOF IDs > I still don't see how adding another UUID field is going to help. > > At the moment, CORBA object references are (pointers to) physical > objects and MOF Identifiers denote the logical identity of objects. > [Yes Martin ... their LOGICAL identity. The MOF 1.3 framework can >be > implemented with two or more CORBA objects with the same MOF >Identifier > ... provided that the implementation does certain things correctly.] >If > we can't keep maintain the invariants for equivalence using MOF > Identifiers in the presence of a 'set' operation, I don't see how we >can > do so with another UUID field. I knew you will mention this. But I think that CORBA object reference equivalence is one more equivalence, which is different from the two I have described. So in fact we have 3 different identities. CORBA or Java or any other technology dependent reference is the most granular equivalence, and my UUIDs determine the least granular equivalence. By that I mean that the following is true: A equals B in sense of reference equivalence => A equals B in sense of MOF IDs equivalence => A equals B in sense of UUIDs equivalence Martin From: "Martin Matula" To: "David Mellor" , "Baisley, Donald E" , , "Stephen Crawley" References: <200107020149.f621n6406102@piglet.dstc.edu.au> Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Date: Mon, 2 Jul 2001 18:12:34 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: GJ#!!T@$e9;@~e9S*/e9 Hi Steve, any two representations of the same object will always have different outermost and immediate package (because their MOF IDs are always generated), possibly also metaobject (if its MOF ID will not be specified explicitly), no matter whether we will or will not define freezing... Martin ----- Original Message ----- From: "Stephen Crawley" To: "Martin Matula" ; "David Mellor" ; "Baisley, Donald E" ; ; Sent: Monday, July 02, 2001 3:49 AM Subject: Re: Issue 2923: mof rtf issue - setting UUIDs > > Folks, > > I think I may have a "solution" to the problem of setting MOF > Identifiers in a loosely federated environment; i.e. one in which > repositories have no knowledge of each other's MOF Identifier <-> >object > mappings. > > The problem with having two physically distinct MOF (instance) >objects > with the same MOF Identifier is that they might end up with >different > state. If we could ensure (to a reasonable degree of confidence) >that > this didn't happen, then there wouldn't be a problem ... I claim. >In > certain circumstances, I think we can do this. > > One way to ensure two copies of an object mean the same thing is to >get > them into the same state then irrevocably disable any further >updates. > If we combine this with MOF's current use of MOF identifiers to >denote > identity, we get a consistent picture of the two objects meaning the > same thing. > > Here's how we could apply this to the MOF -> XMI -> MOF scenario: > > * Define a pervasive notion of a frozen MOF object; i.e. an >object > for which no further updates can occur. > > * When producing an XMI document, record in the document which >MOF > instance objects are frozen. > > * When consuming an XMI document, do the following: > > + If the XMI encoded object is not frozen, create a MOF >object in the > repository with a new MOF identifier. > > + If the XMI encoded object is frozen, the consumer can >EITHER > create a new (frozen or unfrozen) object with a new MOF Identifier > OR create a frozen object with the same MOF Identifier as >the > original MOF object. > > This assumes that nothing can change the state of a frozen object, >and > that the state doesn't get changed in transit; e.g. in the XMI >doecument. > But assuming that, we have an approach for replicating standard >(frozen) > metadata, > > Here is how we could we realise this in the IDL Mapping. > > 1) Codify the semantics of "freezing". It should prevent all >changes > to an instance's attribute values and any "hidden state", but >I > think we shouldn't freeze links > > 2) Change the refSetMofId() operation so that it freezes the >object as > a side-effect. > > 3) Add another operation (say) refFreezeObject() that allows (at >least) > any 'instance' object to be frozen. > > The MOF Model currently has an underspecified notion that a model > element may be in a "frozen" state that disables any further changes > to its state. There is currently an operation (on >Model::ModelElement) > to test to see if a ModelElement is "frozen", and the behaviour of > a "frozen" but there is currently no API to freeze elements. There > is an existing MOF RTF issue (2182) to complete / extend freezing. > > -- Steve > From: "Martin Matula" To: "David Mellor" , "Baisley, Donald E" , "Dirckze, Ravi" , "Stephen Crawley" Cc: References: <200107020223.f622NC409296@piglet.dstc.edu.au> Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Date: Mon, 2 Jul 2001 18:29:10 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: (^/e9Z[7e9OmW!!N%Q!! Hi Steve, in fact, I think that 3b is equal to what I am proposing (the UUID I was mentioning had nothing to do with the MOF object identity defined by MOF IDs). IMO my UUIDs are one possible way of solving 2198 without need to rely on MOF object identity. Please, don't think that by this UUID I mean just another kind of MOF ID. I don't think we need to provide an accessor for this UUID. By that UUID I just wanted to express, what information is sufficient for enabling reuse of existing instances of PrimitiveType - I think it is the fully qualified name (that is what identifies the object logically), not the MOF ID and thus we shouldn't provide the APIs for specifying MOF IDs explicitly. So I vote for option 3b. Martin ----- Original Message ----- From: "Stephen Crawley" To: "David Mellor" ; "Baisley, Donald E" ; "Martin Matula" ; "Dirckze, Ravi" Cc: ; Sent: Monday, July 02, 2001 4:23 AM Subject: Re: Issue 2923: mof rtf issue - setting UUIDs > > Martin, Dave and Don / Ravi, > > Here are what I think our options on UUIDs are: > > 1) Proceed to vote on the 2923 resolution as previously drafted >... with > the problem of federation left for a future RTF. > > 2) Develop (IN SHORT ORDER) a concrete resolution 2182 that >solves the > problem. Then do 2923 and 2182 vote. > > 3) Withdraw 2923 again and don't address it. This leaves us with >a > big hole in the 2198 resolution, so: > > a) Leave the hole; i.e. provide no standard APIs that would >allow > you to deserialise PrimitiveTypes with the correct MOF Identifier. > [Implementors could hack together a proprietary solution >...] > > b) Change the 2198 resolution so that representation of >standard > primitive types does NOT rely on MOF object identity. > > c) Withdraw the 2198 resolution. > > In my view, 3c is not an option. The resolution to 2198 has passed, >and > there would be HUGE resistance to reversing it. Forget it. > > Option 3b is politically tricky. Don / Ravi will have to change >their > positions on this ... and then we'll need to re-vote 2198. > > Option 3a leaves a significant hole in the spec. > > Option 2 is risky. I'm not sure we can get our heads around this >approach > in time. > > Option 1 also leaves a significant hole in the spec. But at least >we > could argue that MOF 1.3 federation is an unsolved problem anyway. > > IMO, option 3b is the technically best solution in the short term >and > option 2 in the long term (e.g. for MOF 1.5). Option 1 is better >than > Option 3a ... but both are nasty. > > -- Steve > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin Matula" cc: "David Mellor" , "Baisley, Donald E" , mof-rtf@omg.org, "Stephen Crawley" , crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from "Martin Matula" of "Mon, 02 Jul 2001 18:12:34 +0200." <0cb601c10311$e2857910$844b9c81@matula> Mime-Version: 1.0 Date: Tue, 03 Jul 2001 07:35:35 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: &HL!!4*1!!T4!"!L]Ke9 Martin, > any two representations of the same object will always have different > outermost and immediate package (because their MOF IDs are always > generated), possibly also metaobject (if its MOF ID will not be specified > explicitly), no matter whether we will or will not define freezing... Yes ... But the fact that two objects have the same outermost/immediate package and the same MOF Identifier does not guarantee that they have the same state. If the two copies of the object have different state, they are no equivalent, by any semantically meaningful definition of equivalent. We've violated the invariant that allowed us to assert "objects have same MOF Identifier <=> objects are logically equivalent". The idea of freezing the objects is to stop some client from violating the invariant. Of course, this assumes that the two copies had the same state to start with. But as I said in another email, resolving the "freezing" issue is risky. We don't have a lot of time to think / talk through the possible problems that freezing might introduce. If 2198 were to depend on freezing, we'd need freezing to be spec'd correctly. I'd prefer to solve this another way. -- Steve From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: Issue 2923: mof rtf issue - setting UUIDs Date: Mon, 2 Jul 2001 16:51:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: p~?e9i~2!!@dLe9=+,e9 Hi all, I thought I should throw in my two cents worth on the UUID issue. If this email is too long, skip to "WHAT CAN WE DO?" at the end. At this time there seems to be three levels of object identification: 1. Object identity of language binding -- this tends to be a memory address or some other low level identification. This level of identify is not very interesting. 2. MOF id -- this tends to correspond with creation of a MOF object. Each creation of a MOF object causes a new unique id to be made for it. It might be the same as level 1 in some systems, but it is likely to be different in system providing persistence, in a distributed system or in a multiuser system providing transactional isolation. Objects do change over time and across versions, so different snapshots or versions of a single model can show the same object in different states, yet with the same MOF id. After all, the object was only created once, so it has a single MOF id, but it exists in different versions of a model. MOF doesn't say anything about versioning, but versioning does happen. 3. UUID -- this is logical identity. This is defined for XMI. It provides a way to make logical connections to objects. Logical identify requires modeling. Databases use primary keys. MOF Model defines a rule for identify: fully qualified name. Some other models have similar rules, others don't. UUID is the most useful type of identify for course grain interaction. It will allow a model represented in XMI to point at standard elements like Primitive::String. It also helps with course grain updates. Here is an example. I export a model from a repository to an XMI document (with UUIDs), I load the XML into a tool, update the model, and write it back to XML. The tool preserves UUIDs of the objects it started with. It makes no UUIDs (of new ones) for new objects it creates in the model. Upon loading the XML back into the repository the UUIDs are used to match objects in the XML file with objects already in the repository. If a matched object has a changed attribute in the XML file, the change is made in the repository. New objects in the XML file are added in the repository. The result is that the model is updated in the repository without existing objects being replaced (which would break links from other models). MOF id should ideally support logical identity also. This would require the ability to replicate models without applying creation semantics that generate new MOF ids. It would also require the ability to optionally state a derivation of MOF id for a class. This can already be done by an implementation. But the MOF Specification does not say anything about it. Since MOF id is defined at the reflective layer rather than being properly modeled, I suppose one could not even define a proper OCL constraint that would state a derivation of MOF id. An implementation can choose to map UUID to MOF id, but there is no standard mapping nor any requirement of a mapping. FREEZING -- I think freezing objects has nothing at all to do with identity. WHAT CAN WE DO? 1. In MOF 1.4 state that ModelElements in MOF Model and MOF PrimitiveTypes packages have UUIDs based on their qualified name. State the pattern of making a UUID so that anyone can make a UUID to refer to any of these standard elements. This gets us past our immediate problem with being able to refer to standard MOF model elements when exchanging models. 2. When we feel ambitious, perhaps for MOF 2.0, we can try to address the issue of modeling logical identify so that the sort of statement we make in number 1 above can be spelled out in a model. At that time we might decide to map MOF id to UUID, or we might not. At any rate, I think logical identification should not be assigned (as in setMofId), but should be derived (which means it could be set indirectly upon creating an object by setting attributes used by the derivation -- in MOF setting name affects the derivation of qualifiedName which affects the derivation of UUID). Let's keep it simple for MOF 1.4 and get ambitious later. Best regards, Don X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Baisley, Donald E" cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from "Baisley, Donald E" of "Mon, 02 Jul 2001 16:51:44 EST." Mime-Version: 1.0 Date: Tue, 03 Jul 2001 09:01:50 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: 8JLe9->Rd9jUkd9X+Y!! Donald.Baisley@unisys.com said: > 1. In MOF 1.4 state that ModelElements in MOF Model and MOF > PrimitiveTypes packages have UUIDs based on their qualified name. > State the pattern of making a UUID so that anyone can make a UUID to > refer to any of these standard elements. This gets us past our > immediate problem with being able to refer to standard MOF model > elements when exchanging models. Don, At the moment the MOF Model does not have an Attribute to hold a UUID, and there is no pseudo-attribute in the (IDL) Reflective layer ... apart from the refMofId(). Are you proposing that we add (say) a UUID Attribute to Model::ModelElement? If so, What invariants are you proposing for the UUID Attribute? [I don't think you are proposing this ... but I just want to be sure, and I want everyone to be clear on this.] What are you proposing to add to the MOF 1.4 to ensure that a UUID (i.e. a qualified name) is unique? For example, if both DSTC and Unisys defined a proprietary primitive data type with the qualified name ExtensionTypes::Date, would they "mean" the same thing? We cannot call an identifier / qualified name a UUID if there are no guarantees of the identifier's uniqueness. It is a blatent abuse of terminology. UUID means Universal Unique IDentifier. In my opinion, the simplest solution is not to talk about UUIDs at all. Simply state in the MOF 1.4 spec (for example) that any PrimitiveType with the name "Boolean" in an outermost Package named "PrimitiveTypes" denotes the MOF built-in Boolean type. Or even drop the requirement on the name of the enclosing Package. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Baisley, Donald E" cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from "Baisley, Donald E" of "Mon, 02 Jul 2001 16:51:44 EST." Mime-Version: 1.0 Date: Tue, 03 Jul 2001 09:43:22 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: ,MTd9T(gd9E@'!!Q4*!! > FREEZING -- I think freezing objects has nothing at all to do with identity. [This is off topic ... assuming that we take the sensible course ... but what the heck.] There are many, many kinds of object equivalence. For example, here are some common kinds (pulling terminology out of the air): * physical identity. Two object share the same area of memory, or more generally, that share the same attribute slots. * logical identity. Two physically distinct objects that behave in such a way that they cannot be distinguished from each other. Objects with logical but not physical identity are often called replicas. * isomorphism. Two logically distinct objects may have the same state at some point in time. Context (e.g. isomorphism of the objects' related objects) is usually also relevant. * conceptual equivalence. Two non-isomorphic objects may still correspond to each other in a conceptual sense. For example, the two objects may represent different versions of some concept. Freezing of objects doesn't define object equality. However, it is a light-weight mechanism for ensuring that physically distinct objects are logically equivalent (in the sense above). If you take a frozen object and copy it (in its context) to produce another frozen object, then a "client" cannot distinguish the object from its copy ... without looking at its "physical" address / object reference. In the MOF 1.4 context, freezing and copying >>would<< allow us to make physically distinct copies of objects that behave as logically identical. At the same time, it avoids the overheads of isomorphic equivalence or conceptual equivalence. But like I said ... I'd prefer an even simpler solution. -- Steve From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: Issue 2923: mof rtf issue - setting UUIDs Date: Mon, 2 Jul 2001 18:54:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: nN,e9Th#!!^+od9bg8!! Hi Steve, I did not make my recommendation for MOF 1.4 clear enough. I hope this helps. The MOF model and semantics say nothing about UUID or xmi.uuid, and I am not proposing to change that for MOF 1.4. I am not proposing a new UUID attribute or any new reflective capability in MOF 1.4. Rather, I am recommending that MOF 1.4 put xmi.uuid attributes into the formal XML documents for MOF Model and MOF PrimitiveTypes on each model element in these packages and that the xmi.uuid values be based on fully qualified name. I am further recommending that these documents have official URLs and that there be a clear pattern by with an HREF in any XMI document can point unambiguously at any model element in these two standard documents. In particular, the XML document for MOF Model will use such HREFs to refer to primitive types it uses. Qualified names in these two packages are unique. My proposal for MOF 1.4 addresses only these two standard packages, so there is no concern at this time about proprietary extensions nor about MOF imposing any constraints at all concerning xmi.uuid (which is an XMI feature, not a MOF feature). Anything more complicated, like providing a way to model logical identity, should be postponed to MOF 2.0. Best regards, Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Monday, July 02, 2001 4:02 PM To: Baisley, Donald E Cc: mof-rtf@omg.org; crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Importance: High Donald.Baisley@unisys.com said: > 1. In MOF 1.4 state that ModelElements in MOF Model and MOF > PrimitiveTypes packages have UUIDs based on their qualified name. > State the pattern of making a UUID so that anyone can make a UUID to > refer to any of these standard elements. This gets us past our > immediate problem with being able to refer to standard MOF model > elements when exchanging models. Don, At the moment the MOF Model does not have an Attribute to hold a UUID, and there is no pseudo-attribute in the (IDL) Reflective layer ... apart from the refMofId(). Are you proposing that we add (say) a UUID Attribute to Model::ModelElement? If so, What invariants are you proposing for the UUID Attribute? [I don't think you are proposing this ... but I just want to be sure, and I want everyone to be clear on this.] What are you proposing to add to the MOF 1.4 to ensure that a UUID (i.e. a qualified name) is unique? For example, if both DSTC and Unisys defined a proprietary primitive data type with the qualified name ExtensionTypes::Date, would they "mean" the same thing? We cannot call an identifier / qualified name a UUID if there are no guarantees of the identifier's uniqueness. It is a blatent abuse of terminology. UUID means Universal Unique IDentifier. In my opinion, the simplest solution is not to talk about UUIDs at all. Simply state in the MOF 1.4 spec (for example) that any PrimitiveType with the name "Boolean" in an outermost Package named "PrimitiveTypes" denotes the MOF built-in Boolean type. Or even drop the requirement on the name of the enclosing Package. -- Steve From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: Issue 2923: mof rtf issue - setting UUIDs Date: Mon, 2 Jul 2001 19:10:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ,9Q!!fB$!!/J)e98d2e9 Hi Steve, The same logical object can appear to have different states when viewed using separate "physical" identities. This is just a synchronization issue. "Same state" is not interesting to me, and I don't think the idea works well on individual objects given that links can exist outside of an object. Two objects might have the same attribute and reference values, but that does not mean that both objects participate in identical Association links. I'm just glad I didn't get frozen in order to get my identity. On the other hand, the final MOF Model XML and PrimitiveTypes XML will eventually be frozen, and soon if we don't get too carried away in MOF 1.4. For now let's just use xmi.uuid where we need it. We can pursue the joys of modeling logical identity later. Enjoy, Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Monday, July 02, 2001 4:43 PM To: Baisley, Donald E Cc: mof-rtf@omg.org; crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Importance: High > FREEZING -- I think freezing objects has nothing at all to do with identity. [This is off topic ... assuming that we take the sensible course ... but what the heck.] There are many, many kinds of object equivalence. For example, here are some common kinds (pulling terminology out of the air): * physical identity. Two object share the same area of memory, or more generally, that share the same attribute slots. * logical identity. Two physically distinct objects that behave in such a way that they cannot be distinguished from each other. Objects with logical but not physical identity are often called replicas. * isomorphism. Two logically distinct objects may have the same state at some point in time. Context (e.g. isomorphism of the objects' related objects) is usually also relevant. * conceptual equivalence. Two non-isomorphic objects may still correspond to each other in a conceptual sense. For example, the two objects may represent different versions of some concept. Freezing of objects doesn't define object equality. However, it is a light-weight mechanism for ensuring that physically distinct objects are logically equivalent (in the sense above). If you take a frozen object and copy it (in its context) to produce another frozen object, then a "client" cannot distinguish the object from its copy ... without looking at its "physical" address / object reference. In the MOF 1.4 context, freezing and copying >>would<< allow us to make physically distinct copies of objects that behave as logically identical. At the same time, it avoids the overheads of isomorphic equivalence or conceptual equivalence. But like I said ... I'd prefer an even simpler solution. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Baisley, Donald E" cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs In-Reply-To: Message from "Baisley, Donald E" of "Mon, 02 Jul 2001 18:54:39 EST." Mime-Version: 1.0 Date: Tue, 03 Jul 2001 10:32:08 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: 8T%"!Kffd90JVd9Pe3e9 Don, One further point of clarification. Are you proposing that the MOF 1.4 spec says that the MOF standard PrimitiveType instances are recognised as such on the basis of their qualified names? For instance, does any PrimitiveType with the qualified name "::PrimitiveTypes::Boolean" denote the standard type Boolean? I'm asking this because it is not what the 2198 amendments currently say. And it is not what you argued for previously. -- Steve From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: Issue 2923: mof rtf issue - setting UUIDs Date: Mon, 2 Jul 2001 19:55:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: N6g!!Wcod9c[^d9P&Ge9 Hi Steve, I will have a very clear identification of Boolean when I have a URI that identifies a specific normative OMG document for a specific version (say 1.4) of MOF PrimitiveTypes, and a specific element named "::PrimitiveTypes::Boolean" within that document. I will have a more fuzzy identification when I simply have a name "::PrimitiveTypes::Boolean". Use of names by themselves implies there is some externally managed configuration that would point at MOF 1.4 or whatever. I don't expect Boolean to change much, but other standard model elements do change between versions. This is just like Java: "java.lang.Boolean" identifies a class, but configuration information (like classpath) determines precisely what class and what version of Java. I don't think we need to standardize how configurations work. Let's just provide xmi.uuid values in support of URIs and assume that MOF's existing rules on uniqueness of qualified names is sufficient. Enjoy, Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Monday, July 02, 2001 5:32 PM To: Baisley, Donald E Cc: mof-rtf@omg.org; crawley@dstc.edu.au Subject: Re: Issue 2923: mof rtf issue - setting UUIDs Importance: High Don, One further point of clarification. Are you proposing that the MOF 1.4 spec says that the MOF standard PrimitiveType instances are recognised as such on the basis of their qualified names? For instance, does any PrimitiveType with the qualified name "::PrimitiveTypes::Boolean" denote the standard type Boolean? I'm asking this because it is not what the 2198 amendments currently say. And it is not what you argued for previously. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: RE: Issue 2923: mof rtf issue - setting UUIDs Mime-Version: 1.0 Date: Thu, 05 Jul 2001 17:10:43 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: 8Fkd9]G(!!R;]!!Fo9e9 Folks, I hereby withdraw the proposed resolution to this issue. Provided that corrigenda #1 to 2198 is acceptable, we do not need to be able to set UUIDs to allow generators to recognise standard PrimitiveType instances. -- Steve