Issue 6345: XMI for TypeLibrary::Objects::Object is Unspecified (mof2xmi-ftf) Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: Issue for XMI for MOF 2 The specification of XMI for MOF 2 does not describe handling of MOF's object type, which is a supertype of ordinary class types as well as data types. Particularly, it does not describe what XML results from the following small example. The whole model is this: In a package M there is one class X having one owned attribute named Y of type TypeLibrary::Objects::Object with multiplicity 1..1. Consider the following 4 instances of X: 1. An instance of X having Y set to the second instance of X. 2. An instance of X having Y set to the integer 3. 3. An instance of X having Y set to the string "this UNICODE string". 4. An instance of X having Y set to that same fourth instance of X. What would an XMI-based serialization of these four instances of X look like? What would an XML schema for the package M look like? Resolution: Revised Text: Actions taken: September 4, 2003: received issue Discussion: End of Annotations:===== m: "Baisley, Donald E" To: issues@omg.org Subject: XMI for TypeLibrary::Objects::Object is Unspecified Date: Thu, 4 Sep 2003 10:43:29 -0500 X-Mailer: Internet Mail Service (5.5.2656.59) Issue for XMI for MOF 2 The specification of XMI for MOF 2 does not describe handling of MOF's object type, which is a supertype of ordinary class types as well as data types. Particularly, it does not describe what XML results from the following small example. The whole model is this: In a package M there is one class X having one owned attribute named Y of type TypeLibrary::Objects::Object with multiplicity 1..1. Consider the following 4 instances of X: 1. An instance of X having Y set to the second instance of X. 2. An instance of X having Y set to the integer 3. 3. An instance of X having Y set to the string "this UNICODE string". 4. An instance of X having Y set to that same fourth instance of X. What would an XMI-based serialization of these four instances of X look like? What would an XML schema for the package M look like? Regards, Don Baisley To: mof2xmi-ftf@omg.org Subject: [mof2xmi-ftf] issue 6345 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Stephen Brodsky Date: Thu, 15 Jan 2004 21:11:09 -0800 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/15/2004 22:11:10, Serialize complete at 01/15/2004 22:11:10 Proposed issue resolution by Tracy Gardner, Barbara Price, Steve Brodsky. Issue 6345: XMI for TypeLibrary::Objects::Object is Unspecified (mof2xmi-ftf) Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com) Nature: Uncategorized Issue Severity: Summary: Issue for XMI for MOF 2 The specification of XMI for MOF 2 does not describe handling of MOF's object type, which is a supertype of ordinary class types as well as data types. Particularly, it does not describe what XML results from the following small example. The whole model is this: In a package M there is one class X having one owned attribute named Y of type TypeLibrary::Objects::Object with multiplicity 1..1. Consider the following 4 instances of X: 1. An instance of X having Y set to the second instance of X. 2. An instance of X having Y set to the integer 3. 3. An instance of X having Y set to the string "this UNICODE string". 4. An instance of X having Y set to that same fourth instance of X. What would an XMI-based serialization of these four instances of X look like? What would an XML schema for the package M look like? Discussion: It looks like this comment was made against an early version of the spec, not the final adopted spec. The mentioned metaclasses are in different places and have been for some time. The type described for Y is now called EMOF:Object. Here is the model: Here is the XSD of the model: Because instances of EMOF:Object are always reflective MOF Objects, constants such as integers (line 2) and strings (line 3) are not valid values for Y. For this example, I have set the values for Y in lines 2 and 3 to some valid value, which I chose to be the same value as in line 4. Here are the XMI instances: Rules referenced: Document production rule 2j XMIReferenceAttribute and 9.5.2 EMOF rules. Actions proposed: None. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Subject: RE: [mof2xmi-ftf] issue 6345 Date: Wed, 21 Jan 2004 08:09:23 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mof2xmi-ftf] issue 6345 Thread-Index: AcPb77MmEAHGnY20RKKalAV92yXEmgELw9FA From: "Pete Rivett" To: "Stephen Brodsky" , As Tracey pointed out on the call, the issue translated to the latest spec should refer to Element not Object: the precise point was how to deal with properties which could be either reflective classes or datatypes - where constants and strings *are* valid values. The proposed resolution does not therefore address the problem. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Stephen Brodsky [mailto:sbrodsky@us.ibm.com] Sent: Friday, January 16, 2004 5:11 AM To: mof2xmi-ftf@omg.org Subject: [mof2xmi-ftf] issue 6345 Proposed issue resolution by Tracy Gardner, Barbara Price, Steve Brodsky. Issue 6345: XMI for TypeLibrary::Objects::Object is Unspecified (mof2xmi-ftf) Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com) Nature: Uncategorized Issue Severity: Summary: Issue for XMI for MOF 2 The specification of XMI for MOF 2 does not describe handling of MOF's object type, which is a supertype of ordinary class types as well as data types. Particularly, it does not describe what XML results from the following small example. The whole model is this: In a package M there is one class X having one owned attribute named Y of type TypeLibrary::Objects::Object with multiplicity 1..1. Consider the following 4 instances of X: 1. An instance of X having Y set to the second instance of X. 2. An instance of X having Y set to the integer 3. 3. An instance of X having Y set to the string "this UNICODE string". 4. An instance of X having Y set to that same fourth instance of X. What would an XMI-based serialization of these four instances of X look like? What would an XML schema for the package M look like? Discussion: It looks like this comment was made against an early version of the spec, not the final adopted spec. The mentioned metaclasses are in different places and have been for some time. The type described for Y is now called EMOF:Object. Here is the model: Here is the XSD of the model: Because instances of EMOF:Object are always reflective MOF Objects, constants such as integers (line 2) and strings (line 3) are not valid values for Y. For this example, I have set the values for Y in lines 2 and 3 to some valid value, which I chose to be the same value as in line 4. Here are the XMI instances: Rules referenced: Document production rule 2j XMIReferenceAttribute and 9.5.2 EMOF rules. Actions proposed: None. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com To: "Pete Rivett" Cc: mof2xmi-ftf@omg.org Subject: RE: [mof2xmi-ftf] issue 6345 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Stephen Brodsky Date: Wed, 21 Jan 2004 21:32:00 -0800 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 01/21/2004 22:32:11, Serialize complete at 01/21/2004 22:32:11 Pete, There are 2 ways to interpret (Object or Element), so we can show an example for both interpretations. Continued discussion: The type described for Y could be interpreted as EMOF:Element. Here is the model: Here is the XSD of the model: Here are the XMI instances: #id.2 3 this UNICODE string #id.4 The xmi:type and xsi:type are used to specify the type of the reference (1, 4) or xml simple type (2, 3) respectively. The EMOF model is missing an XMI tag for EMOF:Element, it should include the XMI tag contentType with value "any". The content model of an Element is XML Schema's Any since that is the XML content model which matches the allowed range of values for Element. Element and XSD:Any are the root of the inheritance tree in the MOF and XML Schema specifications, respectively. Rules referenced: Document production rule 2a XMIObjectElement, 2b XMIValueElement, 2c XMIReferenceElement. Actions proposed: Open an issue with the UML 2 Infrastructure/MOF 2 FTF to add the XMI ContentType tag to EMOF:Element with value "any". Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Pete Rivett" 01/21/2004 05:09 AM To: Stephen Brodsky/Santa Teresa/IBM@IBMUS, cc: Subject: RE: [mof2xmi-ftf] issue 6345 As Tracey pointed out on the call, the issue translated to the latest spec should refer to Element not Object: the precise point was how to deal with properties which could be either reflective classes or datatypes - where constants and strings *are* valid values. The proposed resolution does not therefore address the problem. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Stephen Brodsky [mailto:sbrodsky@us.ibm.com] Sent: Friday, January 16, 2004 5:11 AM To: mof2xmi-ftf@omg.org Subject: [mof2xmi-ftf] issue 6345 Proposed issue resolution by Tracy Gardner, Barbara Price, Steve Brodsky. Issue 6345: XMI for TypeLibrary::Objects::Object is Unspecified (mof2xmi-ftf) Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com) Nature: Uncategorized Issue Severity: Summary: Issue for XMI for MOF 2 The specification of XMI for MOF 2 does not describe handling of MOF's object type, which is a supertype of ordinary class types as well as data types. Particularly, it does not describe what XML results from the following small example. The whole model is this: In a package M there is one class X having one owned attribute named Y of type TypeLibrary::Objects::Object with multiplicity 1..1. Consider the following 4 instances of X: 1. An instance of X having Y set to the second instance of X. 2. An instance of X having Y set to the integer 3. 3. An instance of X having Y set to the string "this UNICODE string". 4. An instance of X having Y set to that same fourth instance of X. What would an XMI-based serialization of these four instances of X look like? What would an XML schema for the package M look like? Discussion: It looks like this comment was made against an early version of the spec, not the final adopted spec. The mentioned metaclasses are in different places and have been for some time. The type described for Y is now called EMOF:Object. Here is the model: Here is the XSD of the model: Because instances of EMOF:Object are always reflective MOF Objects, constants such as integers (line 2) and strings (line 3) are not valid values for Y. For this example, I have set the values for Y in lines 2 and 3 to some valid value, which I chose to be the same value as in line 4. Here are the XMI instances: Rules referenced: Document production rule 2j XMIReferenceAttribute and 9.5.2 EMOF rules. Actions proposed: None. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 Unisys