Issue 6681: UML2 Super/Kernel Classes (uml2-rtf) Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk) Nature: Uncategorized Issue Severity: Summary: section 7.11 Does Property.aggregation have meaning for properties typed by value types, (Data Type and subtypes)? Resolution: Discussion The spec now says under the semantics of Property The semantics of composite aggregation when the container or part is typed by a DataType are intentionally not specified. Disposition: Closed - No Change Revised Text: n subclause 7.3.11 (DataType), under "Semantics", replace the first sentence of the second paragraph: All copies of an instance of a data type and any instances of that data type with the same value are considered to be the same instance. Instances of a data type that have attributes (i.e., is a structured data type) are considered to be the same if the structure is the same and the values of the corresponding attributes are the same. With: All copies of an instance of a data type and any instances of that data type with the same value are considered to be equal instances. Instances of a data type that have attributes (i.e., is a structured data type) are considered to be equal if the structure is the same and the values of the corresponding attributes are equal. Actions taken: December 8, 2003: received issue February 20, 2015: closed issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== m: "Moore, Alan" To: "'issues@omg.org'" Subject: UML2 Super/Kernel Classes Date: Mon, 8 Dec 2003 11:07:37 -0000 X-Mailer: Internet Mail Service (5.5.2653.19) 03-08-02.pdf. section 7.11 Does Property.aggregation have meaning for properties typed by From: "Rouquette, Nicolas F" To: "uml2-rtf@omg.org" Date: Tue, 3 Feb 2009 09:56:45 -0800 Subject: [Classes] resolution for 6681 Thread-Topic: [Classes] resolution for 6681 Thread-Index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeA== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. UML 2.3 Classes 6681 Rouquette.doc Subject: RE: [Classes] resolution for 6681 Date: Tue, 3 Feb 2009 13:10:43 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqng From: "Ed Seidewitz" To: Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. Subject: RE: [Classes] resolution for 6681 Date: Tue, 3 Feb 2009 19:32:38 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwA= From: "Tim Weilkiens" To: "Ed Seidewitz" , Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 X-KeepSent: 3C7222CA:DA3E0545-85257552:00661FF7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Tue, 3 Feb 2009 13:40:00 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 02/03/2009 11:40:01, Serialize complete at 02/03/2009 11:40:01 Ed, I don't have access yet, so couldn't read the issue resolution. But isn't the issue of identity with Class and DataType independent of reference vs. value in Associations since they are all Properties (either of the ownedEnds of the Association or the ownedAttributes of the Class)? Is the property itself that determines the meaning of reference or value determined from the type of the property? From: "Ed Seidewitz" To: Date: 02/03/2009 01:15 PM Subject: RE: [Classes] resolution for 6681 -------------------------------------------------------------------------------- Hmmm.Thiss is interesting. While I see Nicolas.. reasoning, I think I would have answered this issue differently. I don..t really think of two instances of a data type with the same value as being the ..same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of ..identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent ..ownership. of a part by the composite. Without composition, the association is like a reference. However, you can..t have a reference to an instance of a data type . sincee it doesn..t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk..s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. Subject: RE: [Classes] resolution for 6681 Date: Tue, 3 Feb 2009 13:43:29 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAF4yMA== From: "Ed Seidewitz" To: "Tim Weilkiens" Cc: Tim . I am not sure I understand your comment. By .only disallow aggregation., do you mean disallow shared aggregation, but allow composition (which is, of course, a kind of aggregation). What about an association to a data type with no aggregation at all (shared or composite)? -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, February 03, 2009 1:33 PM To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. From: Steve Cook To: Tim Weilkiens , Ed Seidewitz , "uml2-rtf@omg.org" Date: Tue, 3 Feb 2009 18:48:24 +0000 Subject: RE: [Classes] resolution for 6681 Thread-Topic: [Classes] resolution for 6681 Thread-Index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US The issue simply asks a question. Surely the answer is .no., and the resolution is for the spec to say that? I don.t see why anything should be disallowed: as Ed points out, disallowing stuff breaks models. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:33 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. Subject: RE: [Classes] resolution for 6681 Date: Tue, 3 Feb 2009 19:51:50 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzA From: "Tim Weilkiens" To: "Steve Cook" , "Ed Seidewitz" , In other words the aggregation property must be ignored for DataTypes? -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 7:48 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 The issue simply asks a question. Surely the answer is .no., and the resolution is for the spec to say that? I don.t see why anything should be disallowed: as Ed points out, disallowing stuff breaks models. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:33 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. Subject: RE: [Classes] resolution for 6681 Date: Tue, 3 Feb 2009 13:52:45 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGL3MY2F6BxgATQ0yeICvvlo99TwAAHh4A From: "Ed Seidewitz" To: "Jim Amsden" Cc: Jim . I am having a little trouble parsing your last sentence, so forgive me if I am not answering the right question. According to the spec (7.3.11), .A data type is a type whose instances are identified only by their value.. Further, under Semantics it says, .All copies of an instance of a data type and any instances of that data type with the same value are considered to be the same instance. (italics added). This is the basis for the issue and Nicolas. resolution. By the semantics of composition, an instance can only be a part of one composite . which would seemingly mean that you two data type instances with the same value, considered as the same instance, could not be parts of different composites. -- Ed PS: Nicolas attached his resolution to his message, which includes the original issue. -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, February 03, 2009 1:40 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I don't have access yet, so couldn't read the issue resolution. But isn't the issue of identity with Class and DataType independent of reference vs. value in Associations since they are all Properties (either of the ownedEnds of the Association or the ownedAttributes of the Class)? Is the property itself that determines the meaning of reference or value determined from the type of the property? From: "Ed Seidewitz" To: Date: 02/03/2009 01:15 PM Subject: RE: [Classes] resolution for 6681 -------------------------------------------------------------------------------- Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. Subject: RE: [Classes] resolution for 6681 Date: Tue, 3 Feb 2009 13:54:42 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGL3MY2F6BxgATQ0yeICvvlo99TwAAHh4AAAAuUzA= From: "Ed Seidewitz" To: "Jim Amsden" Cc: Oops.I meant to add another paragraph saying that, while Nicolas. resolution thus seems logical, I am afraid that it may go against common data modeling practice with UML. An alternative resolution might be to revise the semantics text under 7.3.11 to clarify the implications of .same value. so it doesn.t seem to conflict with composition. -------------------------------------------------------------------------------- From: Ed Seidewitz Sent: Tuesday, February 03, 2009 1:53 PM To: 'Jim Amsden' Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Jim . I am having a little trouble parsing your last sentence, so forgive me if I am not answering the right question. According to the spec (7.3.11), .A data type is a type whose instances are identified only by their value.. Further, under Semantics it says, .All copies of an instance of a data type and any instances of that data type with the same value are considered to be the same instance. (italics added). This is the basis for the issue and Nicolas. resolution. By the semantics of composition, an instance can only be a part of one composite . which would seemingly mean that you two data type instances with the same value, considered as the same instance, could not be parts of different composites. -- Ed PS: Nicolas attached his resolution to his message, which includes the original issue. -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, February 03, 2009 1:40 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I don't have access yet, so couldn't read the issue resolution. But isn't the issue of identity with Class and DataType independent of reference vs. value in Associations since they are all Properties (either of the ownedEnds of the Association or the ownedAttributes of the Class)? Is the property itself that determines the meaning of reference or value determined from the type of the property? From: "Ed Seidewitz" To: Date: 02/03/2009 01:15 PM Subject: RE: [Classes] resolution for 6681 -------------------------------------------------------------------------------- Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. From: Steve Cook To: Tim Weilkiens , Ed Seidewitz , "uml2-rtf@omg.org" Date: Tue, 3 Feb 2009 18:55:59 +0000 Subject: RE: [Classes] resolution for 6681 Thread-Topic: [Classes] resolution for 6681 Thread-Index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Yes. And the multiplicity, and the navigability. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:52 To: Steve Cook; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 In other words the aggregation property must be ignored for DataTypes? -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 7:48 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 The issue simply asks a question. Surely the answer is .no., and the resolution is for the spec to say that? I don.t see why anything should be disallowed: as Ed points out, disallowing stuff breaks models. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:33 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. Subject: RE: [Classes] resolution for 6681 Date: Tue, 3 Feb 2009 14:02:43 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkA== From: "Ed Seidewitz" To: "Steve Cook" Cc: Steve . No, the multiplicity and navigability should not be ignored. There is certainly a difference between an association to 1 instance of a data type versus many. It is just that, for data types, uniqueness is determined by value equality, not identity equality. And, in particular, if the data type is a structured data type (that is, one with attributes, not a primitive type or enumeration) than navigability is also relevant. In any case, for composition, there is still a reasonable perception of a conflict with the data type semantics as stated in 7.3.11. If we want the answer to the question asked in the issue to be .no., then we probably should clarify the text in 7.3.11 to remove this possible perception. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 1:56 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Yes. And the multiplicity, and the navigability. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:52 To: Steve Cook; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 In other words the aggregation property must be ignored for DataTypes? -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 7:48 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 The issue simply asks a question. Surely the answer is .no., and the resolution is for the spec to say that? I don.t see why anything should be disallowed: as Ed points out, disallowing stuff breaks models. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:33 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. From: Steve Cook To: Ed Seidewitz CC: "uml2-rtf@omg.org" Date: Tue, 3 Feb 2009 20:40:41 +0000 Subject: RE: [Classes] resolution for 6681 Thread-Topic: [Classes] resolution for 6681 Thread-Index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8Tg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed I am referring to the other end. If I have a composition to the primitive type Integer, what is the meaning of the 1 on the composition end of the association? It means that each Integer only has one owner, right? So who is the owner of 42? And what can I navigate from 42 to? I fully agree with your second sentence. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 03 February 2009 19:03 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Steve . No, the multiplicity and navigability should not be ignored. There is certainly a difference between an association to 1 instance of a data type versus many. It is just that, for data types, uniqueness is determined by value equality, not identity equality. And, in particular, if the data type is a structured data type (that is, one with attributes, not a primitive type or enumeration) than navigability is also relevant. In any case, for composition, there is still a reasonable perception of a conflict with the data type semantics as stated in 7.3.11. If we want the answer to the question asked in the issue to be .no., then we probably should clarify the text in 7.3.11 to remove this possible perception. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 1:56 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Yes. And the multiplicity, and the navigability. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:52 To: Steve Cook; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 In other words the aggregation property must be ignored for DataTypes? -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 7:48 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 The issue simply asks a question. Surely the answer is .no., and the resolution is for the spec to say that? I don.t see why anything should be disallowed: as Ed points out, disallowing stuff breaks models. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:33 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. Subject: RE: [Classes] resolution for 6681 Date: Tue, 3 Feb 2009 15:53:56 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAACG7wA= From: "Ed Seidewitz" To: "Steve Cook" Cc: Steve . You are right, multiplicity on the composition end is kind of meaningless. Which, perhaps, is the very issue in a nutshell. Navigability, on the other hand, does make sense on the composition end, but only, as I said, if the data type on the other end is a structured data type . not a primitive type (like Integer) or an enumeration. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 3:41 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed I am referring to the other end. If I have a composition to the primitive type Integer, what is the meaning of the 1 on the composition end of the association? It means that each Integer only has one owner, right? So who is the owner of 42? And what can I navigate from 42 to? I fully agree with your second sentence. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 03 February 2009 19:03 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Steve . No, the multiplicity and navigability should not be ignored. There is certainly a difference between an association to 1 instance of a data type versus many. It is just that, for data types, uniqueness is determined by value equality, not identity equality. And, in particular, if the data type is a structured data type (that is, one with attributes, not a primitive type or enumeration) than navigability is also relevant. In any case, for composition, there is still a reasonable perception of a conflict with the data type semantics as stated in 7.3.11. If we want the answer to the question asked in the issue to be .no., then we probably should clarify the text in 7.3.11 to remove this possible perception. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 1:56 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Yes. And the multiplicity, and the navigability. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:52 To: Steve Cook; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 In other words the aggregation property must be ignored for DataTypes? -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 7:48 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 The issue simply asks a question. Surely the answer is .no., and the resolution is for the spec to say that? I don.t see why anything should be disallowed: as Ed points out, disallowing stuff breaks models. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:33 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. Date: Tue, 03 Feb 2009 16:30:13 -0500 From: "Chonoles, Michael J" Subject: RE: [Classes] resolution for 6681 To: Ed Seidewitz , Steve Cook Cc: uml2-rtf@omg.org Thread-Topic: [Classes] resolution for 6681 Thread-Index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAACG7wAAAUStEA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 03 Feb 2009 21:30:15.0780 (UTC) FILETIME=[9AAF9240:01C98646] I wish to agree fully with the position that Ed and Steve appear to coming to . changing this would break many many models, and would invalidate many books and training materials going back to the origins of UML. Michael LMCO From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 3:54 PM To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Steve . You are right, multiplicity on the composition end is kind of meaningless. Which, perhaps, is the very issue in a nutshell. Navigability, on the other hand, does make sense on the composition end, but only, as I said, if the data type on the other end is a structured data type . not a primitive type (like Integer) or an enumeration. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 3:41 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed I am referring to the other end. If I have a composition to the primitive type Integer, what is the meaning of the 1 on the composition end of the association? It means that each Integer only has one owner, right? So who is the owner of 42? And what can I navigate from 42 to? I fully agree with your second sentence. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 03 February 2009 19:03 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Steve . No, the multiplicity and navigability should not be ignored. There is certainly a difference between an association to 1 instance of a data type versus many. It is just that, for data types, uniqueness is determined by value equality, not identity equality. And, in particular, if the data type is a structured data type (that is, one with attributes, not a primitive type or enumeration) than navigability is also relevant. In any case, for composition, there is still a reasonable perception of a conflict with the data type semantics as stated in 7.3.11. If we want the answer to the question asked in the issue to be .no., then we probably should clarify the text in 7.3.11 to remove this possible perception. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 1:56 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Yes. And the multiplicity, and the navigability. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:52 To: Steve Cook; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 In other words the aggregation property must be ignored for DataTypes? -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 7:48 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 The issue simply asks a question. Surely the answer is .no., and the resolution is for the spec to say that? I don.t see why anything should be disallowed: as Ed points out, disallowing stuff breaks models. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:33 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. Subject: RE: [Classes] resolution for 6681 Date: Tue, 3 Feb 2009 15:28:26 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 Thread-Index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAACG7wAAArDwAA== From: "Pete Rivett" To: "Ed Seidewitz" , "Steve Cook" , "Rouquette, Nicolas F" Cc: For DataType in 7.3.11 the spec has: .All copies of an instance of a data type and any instances of that data type with the same value are considered to be the same instance. . Which is not to say they are the same instance. In 7.3.2 for composite it states: .Indicates that the property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (parts).. In 7.3.3, it states the following (though this is in the section for Associations so it.s unclear whether it applies to composite Properties which are not members of Associations): .Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.. Aside: The latter seems a lot clearer and is free from the somewhat undefined and anthropomorphic notion of .responsibility.. And of storage. Which seems to be a minefield with some consequences that we might not want to have in scope as per the following reductio ad absurdum which I only include to support a proposal that we expunge any reference to storage management. We also need to tighten the definition of ReadExtentAction. So it seems that the above implies: a) You can have multiple copies of a datatype instance, which are all equal and identical b) Each may consume some storage c) Once assigned to a composite property, the instance of the classifier owning that property (which may be a class or datatype) becomes .responsible. for the storage of the datatype instance d) So if that classifier instance is deleted the datatype instance storage is deleted/freed e) However if the classifier instance composite property is unset, or assigned a new value for the property, then presumably the datatype instance still exists in some form and continues to occupy storage though with nothing .responsible. for it f) Such datatype instances could potentially be discovered using ReadExtentAction (which operates on Classifiers) and then assigned to the composite property of a different classifier instance. But not if there is more than one copy of the same value since ReadExtentAction is defined to return a set. (this might be controversial . I assume that ReadExtentAction will only return Datatype instances that actually exist (though having been used and not deleted by their responsible object if any) . so it cannot be used to enumerate all Integers for example. In the same way it cannot be used to conjure up all conceivable instances of the class Person, which may well all have the same property values). g) For datatyped properties which are not composite, no object is responsible for their storage so it reverts to .the system.. h) The .system. is responsible for keeping track of unique datatype values that have been used in order to satisfy requests to ReadExtentAction as above So, to answer the original issue 6681, with .storage. in the spec, then .composite. certainly does have meaning for datatyped properties. And even .shared. aggregation could be taken as a hint that an implementation should optimize/reuse storage of values (in the same way that navigability is a hint for implementations to make navigation efficient) Some other points: Since a Property may or may not be a member of an Association (owned or not), and the .attribute. notation may be used for both, and in both cases the property is linked to the class via ownedAttribute, then diagrams become ambiguous and it becomes pretty hard to work out if there is an association or not. Or, in most tools, for the user to specify one option or the other. Where a property is typed by a Class, what precise (semantic and practical) difference does it make whether it is a member of an Association or not? I don.t understand Ed.s point (in receding email) that .navigability does make sense. (taking the .new. definition of navigability as .ease of navigation.) and why on earth it should matter whether the target datatype is structured or not. In the proposed Resolution for 6681, I don.t see what justifies condition 1): why does the question not apply to a property owned by an Association? The semantics of Association are defined in terms of tuples (links) of typed instances . there seems at the moment to be nothing to prevent these being Datatype instances. Or, conversely, for the property of a Datatype to be typed by a Class. In many .real world. models I have seen Classes used instead of structured Datatypes . for example Date (modeled using properties for Day Month and Year). Is this ever valid (semantically) or useful? In several places the spec refers to Slots when defining the semantics of Property. This seems IMHO wrong, since Slot is specifically defined for the user to model InstanceSpecifications and the concept is insufficiently defined to usefully work for semantic definition in the UML spec itself. For example 7.3.44 says .When a property is an attribute of a classifier, the value or values are related to the instance of the classifier by being held in slots of the instance.. This has no useful meaning, since the bulk of real instances of a Class will have no InstanceSpecification which is the only place Slot is defined. Conversely the concept of Link (used to specify the semantics of Association) is better defined . in terms of tuples which is a widely understood mathematical abstraction. Sorry to open up rather than close down the discussion, but I think if we get clarity on some of the above points it will help us with a number of issues in this area, as well as cleaning up the spec somewhat. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 03 February 2009 12:54 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Steve . You are right, multiplicity on the composition end is kind of meaningless. Which, perhaps, is the very issue in a nutshell. Navigability, on the other hand, does make sense on the composition end, but only, as I said, if the data type on the other end is a structured data type . not a primitive type (like Integer) or an enumeration. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 3:41 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed I am referring to the other end. If I have a composition to the primitive type Integer, what is the meaning of the 1 on the composition end of the association? It means that each Integer only has one owner, right? So who is the owner of 42? And what can I navigate from 42 to? I fully agree with your second sentence. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 03 February 2009 19:03 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Steve . No, the multiplicity and navigability should not be ignored. There is certainly a difference between an association to 1 instance of a data type versus many. It is just that, for data types, uniqueness is determined by value equality, not identity equality. And, in particular, if the data type is a structured data type (that is, one with attributes, not a primitive type or enumeration) than navigability is also relevant. In any case, for composition, there is still a reasonable perception of a conflict with the data type semantics as stated in 7.3.11. If we want the answer to the question asked in the issue to be .no., then we probably should clarify the text in 7.3.11 to remove this possible perception. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 1:56 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Yes. And the multiplicity, and the navigability. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:52 To: Steve Cook; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 In other words the aggregation property must be ignored for DataTypes? -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 7:48 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 The issue simply asks a question. Surely the answer is .no., and the resolution is for the spec to say that? I don.t see why anything should be disallowed: as Ed points out, disallowing stuff breaks models. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:33 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. Subject: RE: [Classes] resolution for 6681 Date: Tue, 3 Feb 2009 15:39:29 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 Thread-Index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jA= From: "Pete Rivett" To: "Steve Cook" Cc: "Ed Seidewitz" , I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 03 February 2009 12:41 To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed I am referring to the other end. If I have a composition to the primitive type Integer, what is the meaning of the 1 on the composition end of the association? It means that each Integer only has one owner, right? So who is the owner of 42? And what can I navigate from 42 to? I fully agree with your second sentence. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 03 February 2009 19:03 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Steve . No, the multiplicity and navigability should not be ignored. There is certainly a difference between an association to 1 instance of a data type versus many. It is just that, for data types, uniqueness is determined by value equality, not identity equality. And, in particular, if the data type is a structured data type (that is, one with attributes, not a primitive type or enumeration) than navigability is also relevant. In any case, for composition, there is still a reasonable perception of a conflict with the data type semantics as stated in 7.3.11. If we want the answer to the question asked in the issue to be .no., then we probably should clarify the text in 7.3.11 to remove this possible perception. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 1:56 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Yes. And the multiplicity, and the navigability. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:52 To: Steve Cook; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 In other words the aggregation property must be ignored for DataTypes? -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 7:48 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 The issue simply asks a question. Surely the answer is .no., and the resolution is for the spec to say that? I don.t see why anything should be disallowed: as Ed points out, disallowing stuff breaks models. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:33 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. From: "Rouquette, Nicolas F" To: Pete Rivett , Ed Seidewitz , Steve Cook CC: "uml2-rtf@omg.org" Date: Tue, 3 Feb 2009 16:21:10 -0800 Subject: RE: [Classes] resolution for 6681 Thread-Topic: [Classes] resolution for 6681 Thread-Index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAACG7wAAArDwAAADTGrg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Pete, Per your analysis, I think we should answer yes to 6681 which makes it pertinent to [Classes] #11287. Besides having implications on clarification changes that we need to make to the spec, I would interpret your helpful analysis in the following way: (a), (b), (c), (d) => composite aggregation (a), (b), (e), (f) => shared aggregation (subject to the SVP in 7.3.2) (a), (b), (g) => no aggregation See below for the other points. From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 3:28 PM To: Ed Seidewitz; Steve Cook; Rouquette, Nicolas F Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 For DataType in 7.3.11 the spec has: .All copies of an instance of a data type and any instances of that data type with the same value are considered to be the same instance. . Which is not to say they are the same instance. In 7.3.2 for composite it states: .Indicates that the property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (parts).. In 7.3.3, it states the following (though this is in the section for Associations so it.s unclear whether it applies to composite Properties which are not members of Associations): .Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.. Aside: The latter seems a lot clearer and is free from the somewhat undefined and anthropomorphic notion of .responsibility.. And of storage. Which seems to be a minefield with some consequences that we might not want to have in scope as per the following reductio ad absurdum which I only include to support a proposal that we expunge any reference to storage management. We also need to tighten the definition of ReadExtentAction. So it seems that the above implies: a) You can have multiple copies of a datatype instance, which are all equal and identical b) Each may consume some storage c) Once assigned to a composite property, the instance of the classifier owning that property (which may be a class or datatype) becomes .responsible. for the storage of the datatype instance d) So if that classifier instance is deleted the datatype instance storage is deleted/freed e) However if the classifier instance composite property is unset, or assigned a new value for the property, then presumably the datatype instance still exists in some form and continues to occupy storage though with nothing .responsible. for it f) Such datatype instances could potentially be discovered using ReadExtentAction (which operates on Classifiers) and then assigned to the composite property of a different classifier instance. But not if there is more than one copy of the same value since ReadExtentAction is defined to return a set. (this might be controversial . I assume that ReadExtentAction will only return Datatype instances that actually exist (though having been used and not deleted by their responsible object if any) . so it cannot be used to enumerate all Integers for example. In the same way it cannot be used to conjure up all conceivable instances of the class Person, which may well all have the same property values). g) For datatyped properties which are not composite, no object is responsible for their storage so it reverts to .the system.. h) The .system. is responsible for keeping track of unique datatype values that have been used in order to satisfy requests to ReadExtentAction as above So, to answer the original issue 6681, with .storage. in the spec, then .composite. certainly does have meaning for datatyped properties. And even .shared. aggregation could be taken as a hint that an implementation should optimize/reuse storage of values (in the same way that navigability is a hint for implementations to make navigation efficient) Some other points: Since a Property may or may not be a member of an Association (owned or not), and the .attribute. notation may be used for both, and in both cases the property is linked to the class via ownedAttribute, then diagrams become ambiguous and it becomes pretty hard to work out if there is an association or not. Or, in most tools, for the user to specify one option or the other. [NFR] Agreed but this would expand the scope of 6681. Where a property is typed by a Class, what precise (semantic and practical) difference does it make whether it is a member of an Association or not? [NFR] In that case, constraint [4] on 7.3.3 applies: only binary associations can be aggregations. 6681 isn.t about this case. I don.t understand Ed.s point (in receding email) that .navigability does make sense. (taking the .new. definition of navigability as .ease of navigation.) and why on earth it should matter whether the target datatype is structured or not. [NFR] Ed? This also pertains to [Classes] #8921 and #9961 In the proposed Resolution for 6681, I don.t see what justifies condition 1): why does the question not apply to a property owned by an Association? The semantics of Association are defined in terms of tuples (links) of typed instances . there seems at the moment to be nothing to prevent these being Datatype instances. Or, conversely, for the property of a Datatype to be typed by a Class. [NFR] Mea culpa, (1) should apply to the attribute properties of an association as well (i.e., association ends are out of scope of 6681) In many .real world. models I have seen Classes used instead of structured Datatypes . for example Date (modeled using properties for Day Month and Year). Is this ever valid (semantically) or useful? [NFR] If the type of the Day, Month, Year properties isn.t a datatype, then I would say that this isn.t valid UML unless one is taking a careful, least commitment approach to interpreting to 7.3.44 and 7.3.3 In several places the spec refers to Slots when defining the semantics of Property. This seems IMHO wrong, since Slot is specifically defined for the user to model InstanceSpecifications and the concept is insufficiently defined to usefully work for semantic definition in the UML spec itself. For example 7.3.44 says .When a property is an attribute of a classifier, the value or values are related to the instance of the classifier by being held in slots of the instance.. This has no useful meaning, since the bulk of real instances of a Class will have no InstanceSpecification which is the only place Slot is defined. Conversely the concept of Link (used to specify the semantics of Association) is better defined . in terms of tuples which is a widely understood mathematical abstraction. [NFR] This point pertains to [Classes] #6497, #10140 Sorry to open up rather than close down the discussion, but I think if we get clarity on some of the above points it will help us with a number of issues in this area, as well as cleaning up the spec somewhat. [NFR] Agreed and I.m thankful for all of the constructive discussion on this issue. n Nicolas. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 03 February 2009 12:54 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Steve . You are right, multiplicity on the composition end is kind of meaningless. Which, perhaps, is the very issue in a nutshell. Navigability, on the other hand, does make sense on the composition end, but only, as I said, if the data type on the other end is a structured data type . not a primitive type (like Integer) or an enumeration. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 3:41 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed I am referring to the other end. If I have a composition to the primitive type Integer, what is the meaning of the 1 on the composition end of the association? It means that each Integer only has one owner, right? So who is the owner of 42? And what can I navigate from 42 to? I fully agree with your second sentence. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 03 February 2009 19:03 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Steve . No, the multiplicity and navigability should not be ignored. There is certainly a difference between an association to 1 instance of a data type versus many. It is just that, for data types, uniqueness is determined by value equality, not identity equality. And, in particular, if the data type is a structured data type (that is, one with attributes, not a primitive type or enumeration) than navigability is also relevant. In any case, for composition, there is still a reasonable perception of a conflict with the data type semantics as stated in 7.3.11. If we want the answer to the question asked in the issue to be .no., then we probably should clarify the text in 7.3.11 to remove this possible perception. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 1:56 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Yes. And the multiplicity, and the navigability. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:52 To: Steve Cook; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 In other words the aggregation property must be ignored for DataTypes? -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, February 03, 2009 7:48 PM To: Tim Weilkiens; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 The issue simply asks a question. Surely the answer is .no., and the resolution is for the spec to say that? I don.t see why anything should be disallowed: as Ed points out, disallowing stuff breaks models. -- Steve From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 03 February 2009 18:33 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Ed, I agree with your statements. I would prefer to only disallow aggregation for DataTypes. Implicitly that's already a fact, because there is no reference. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, February 03, 2009 7:11 PM To: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Hmmm.This is interesting. While I see Nicolas. reasoning, I think I would have answered this issue differently. I don.t really think of two instances of a data type with the same value as being the .same instance.. Rather, I would say they are just equal instances, and that their equality is based on value, rather than identity. The whole concept of .identity. rather than value is just not really defined for instances of data types. Now, composition is often used in models to represent .ownership. of a part by the composite. Without composition, the association is like a reference. However, you can.t have a reference to an instance of a data type . since it doesn.t have an identity to refer to . so it is also a common convention to model all associations to data types as composition. This would, of course, be disallowed by the resolution Nicolas is proposing. I would be interested in what other folk.s intuition is on this. I am worried that by disallowing composition on data type properties, we will be invalidating a lot of models already done by data modelers out there. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, February 03, 2009 12:57 PM To: uml2-rtf@omg.org Subject: [Classes] resolution for 6681 https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Resolutions/Ballot1/UML 2.3 Classes 6681 Rouquette.doc http://www.omg.org/issues/uml2-rtf.open.html#Issue6681 n Nicolas. Subject: RE: [Classes] resolution for 6681 Date: Wed, 4 Feb 2009 10:29:58 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jAAHxVFgA== From: "Ed Seidewitz" To: "Pete Rivett - Adaptive" , "Steve Cook" Cc: Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 6:39 PM To: Steve Cook Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). [EVS] That.s also the way I tend to think of it. Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. [EVS] I guess I was still stuck in the mode of thinking of owned opposite association ends. It certainly does not make sense for Integer to own an association end. However, if the association end is owned by the association, then it is certainly possible to navigate the association using a read link action, as you indicate. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? [EVS] Well, it is hard to reference the spec to answer your questions, since it is not entirely clear, in terms of the spec, what your questions even mean. However, since Integer is a primitive type, I suppose we could start out with the semantics of PrimitiveType (7.3.43): .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). .Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.. [EVS] I read this as meaning that two instances of the same primitive type with the same representation are indistinguishable (and, in passing, I note that it says they are .indistinguishable., not .the same.). The spec doesn.t say anything about equality of values across different data types. In fact, there is no general semantic concept of .equality. in UML, so you really can.t answer the question .is a value of one type equal to the value of another type. by referencing the spec . the answer is user model dependent. UML does have a test identity action (11.3.49), but this only tests if two input values .are the same identity.. It is not clear what the semantics of this is when the input values are data values which .do not have identity.. In fUML, the semantics of the test identity action was extended to provide a general equality test in the case of data values (see fUML Specification, 8.6.3), so let.s use that. However, it is not clear how to represent .(PositiveInteger)42. in UML. UML only has built-in literals for the four primitive types defined within the UML standard. Nevertheless, it is possible to give a value specification a type (see 7.3.54 . ValueSpecification is a TypedElement), regardless of what kind of value specification it is. Therefore, one could create a LiteralInteger with a value of 42 and a type of PositiveInteger (presumably there would need to be some constraint that the values of literals of type PositiveInteger are actually positive integers, but I don.t know that there is any way to formally specify this in UML.). In fUML, two literal integers as above evaluate to two integer values, both with the value 42, but one with the type Integer and the other with the type PositiveInteger (see fUML Specification, 8.3.2.2.14 . note that the call .this.getType(.Integer.). only gets the built-in Integer type if no type is given for the literal integer, otherwise it returns the type as given in the model). If these two integer values are input to a test identity action execution, they will, indeed, be considered equal, because the equality test for integer values just tests for equality of values, regardless of the types (see fUML Specification, 8.3.2.2.10). So, interestingly enough, PositiveInteger instances are represented as fUML integer values at execution time, then the answer to the first question is .yes. and the answer to the second question is .no. for fUML. -- Ed Subject: RE: [Classes] resolution for 6681 Date: Wed, 4 Feb 2009 11:14:31 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jAAHxVFgAADjNqg From: "Cory Casanave" To: "Ed Seidewitz" , "Pete Rivett - Adaptive" , "Steve Cook" Cc: If you accept the semantics that type is a predicate, then 42 satisfies the predicate of both integer and positive integer. There is nothing inconsistent with it satisfying both types. I also don.t think this idea of a .copy of 42. makes any sense. You can have a slot for a number containing 42 or a representation of 42 (as a string or in 32 binary digits) . but I don.t think you can copy something that is purely a value. What we are doing in computer programs is manipulating slots (memory locations) that contain a representation of some value, but, committing to such concepts with respect to the definition of values would be to over-commit that concept to a particular computational system. Within the computational system of slots the difference between 42 (in an integer slot) and 42 (in an unsigned integer slot) is significant only with respect to the slot as a constraint on the values it may contain. The value in the slot is unaffected by (and not owned by) that slot. It can, of course, be hard to conceptualize some of these things without grounding it in a computational system . but it is worth trying. So I would agree with Nicolas that all representations of 42 represent the same individual universally. We should not confuse representations (signs in some terminologies) with the thing being represented. -Cory -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, February 04, 2009 10:30 AM To: Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 6:39 PM To: Steve Cook Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). [EVS] That.s also the way I tend to think of it. Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. [EVS] I guess I was still stuck in the mode of thinking of owned opposite association ends. It certainly does not make sense for Integer to own an association end. However, if the association end is owned by the association, then it is certainly possible to navigate the association using a read link action, as you indicate. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? [EVS] Well, it is hard to reference the spec to answer your questions, since it is not entirely clear, in terms of the spec, what your questions even mean. However, since Integer is a primitive type, I suppose we could start out with the semantics of PrimitiveType (7.3.43): .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). .Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.. [EVS] I read this as meaning that two instances of the same primitive type with the same representation are indistinguishable (and, in passing, I note that it says they are .indistinguishable., not .the same.). The spec doesn.t say anything about equality of values across different data types. In fact, there is no general semantic concept of .equality. in UML, so you really can.t answer the question .is a value of one type equal to the value of another type. by referencing the spec . the answer is user model dependent. UML does have a test identity action (11.3.49), but this only tests if two input values .are the same identity.. It is not clear what the semantics of this is when the input values are data values which .do not have identity.. In fUML, the semantics of the test identity action was extended to provide a general equality test in the case of data values (see fUML Specification, 8.6.3), so let.s use that. However, it is not clear how to represent .(PositiveInteger)42. in UML. UML only has built-in literals for the four primitive types defined within the UML standard. Nevertheless, it is possible to give a value specification a type (see 7.3.54 . ValueSpecification is a TypedElement), regardless of what kind of value specification it is. Therefore, one could create a LiteralInteger with a value of 42 and a type of PositiveInteger (presumably there would need to be some constraint that the values of literals of type PositiveInteger are actually positive integers, but I don.t know that there is any way to formally specify this in UML.). In fUML, two literal integers as above evaluate to two integer values, both with the value 42, but one with the type Integer and the other with the type PositiveInteger (see fUML Specification, 8.3.2.2.14 . note that the call .this.getType(.Integer.). only gets the built-in Integer type if no type is given for the literal integer, otherwise it returns the type as given in the model). If these two integer values are input to a test identity action execution, they will, indeed, be considered equal, because the equality test for integer values just tests for equality of values, regardless of the types (see fUML Specification, 8.3.2.2.10). So, interestingly enough, PositiveInteger instances are represented as fUML integer values at execution time, then the answer to the first question is .yes. and the answer to the second question is .no. for fUML. -- Ed Subject: RE: [Classes] resolution for 6681 Date: Wed, 4 Feb 2009 11:45:30 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jAAHxVFgAADjNqgAACnPfA= From: "Ed Seidewitz" To: "Cory Casanave" Cc: Cory . There is the semantics that one might accept, and the semantics that is actually specified for UML (such as it is.). The semantics for PrimitiveType that I quoted makes a distinction between .data values. that are instances of the type and the .mathematical elements defined outside of UML. represented by those data values. In fact, there is a .many-to-one correspondence. between data values and mathematical elements, which, for integers, would indicate that there can be more than one Integer data value for the same mathematical integer. This is pretty directly reflected in the more precise semantics of fUML. The fUML execution model includes the class IntegerValue, which is a subclass of DataValue (see fUML Spec, 8.3.2). IntegerValue has an attribute .value. of type Integer. The type Integer, as used in the execution model, is to be interpreted with the base semantics of bUML, which maps it to the set of mathematical integers (fUML Spec, 10.3.1.2). So, in fUML, there can, indeed, be more than one IntegerValue with the same mathematical integer value . and, in fact, one is created every time something evaluates to or outputs an integer value. However, these are .indistinguishable. from each other in the sense that any two IntegerValues with the same underlying value are equal and interchangeable. In effect, we have LiteralInteger as the syntactic representation of an integer in UML, IntegerValue as the semantic representation in fUML (which, for integers, is actually isomorphic to the syntactic representation) and both of these are, ultimately, representations of the mathematical concept of an integer. And I agree that every literal integer for 42 and every integer value for 42 represents the same individual mathematical 42 universally. Note that the same kind of interpretation applies for the other standard UML primitive types: Boolean, UnlimitedNatural and String. The case of enumerations and structured data types is a little sticker in fUML, since neither of these kinds of data types is included in bUML, so the fUML spec does not give them a direct base semantics. Nevertheless, in principle one could map instances of enumerations and structured data types to appropriate mathematical elements (e.g., tuples for structured data types) for which the idea of a many-to-one representation of universal individuals would still apply. Of course, there are certainly many ways to think about this, but the above is based on what the spec says . which is what Pete asked for. And rightly so, since, in the RTF, the spec is our baseline. -- Ed -------------------------------------------------------------------------------- From: Cory Casanave Sent: Wednesday, February 04, 2009 11:15 AM To: Ed Seidewitz; Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 If you accept the semantics that type is a predicate, then 42 satisfies the predicate of both integer and positive integer. There is nothing inconsistent with it satisfying both types. I also don.t think this idea of a .copy of 42. makes any sense. You can have a slot for a number containing 42 or a representation of 42 (as a string or in 32 binary digits) . but I don.t think you can copy something that is purely a value. What we are doing in computer programs is manipulating slots (memory locations) that contain a representation of some value, but, committing to such concepts with respect to the definition of values would be to over-commit that concept to a particular computational system. Within the computational system of slots the difference between 42 (in an integer slot) and 42 (in an unsigned integer slot) is significant only with respect to the slot as a constraint on the values it may contain. The value in the slot is unaffected by (and not owned by) that slot. It can, of course, be hard to conceptualize some of these things without grounding it in a computational system . but it is worth trying. So I would agree with Nicolas that all representations of 42 represent the same individual universally. We should not confuse representations (signs in some terminologies) with the thing being represented. -Cory -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, February 04, 2009 10:30 AM To: Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 6:39 PM To: Steve Cook Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). [EVS] That.s also the way I tend to think of it. Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. [EVS] I guess I was still stuck in the mode of thinking of owned opposite association ends. It certainly does not make sense for Integer to own an association end. However, if the association end is owned by the association, then it is certainly possible to navigate the association using a read link action, as you indicate. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? [EVS] Well, it is hard to reference the spec to answer your questions, since it is not entirely clear, in terms of the spec, what your questions even mean. However, since Integer is a primitive type, I suppose we could start out with the semantics of PrimitiveType (7.3.43): .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). .Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.. [EVS] I read this as meaning that two instances of the same primitive type with the same representation are indistinguishable (and, in passing, I note that it says they are .indistinguishable., not .the same.). The spec doesn.t say anything about equality of values across different data types. In fact, there is no general semantic concept of .equality. in UML, so you really can.t answer the question .is a value of one type equal to the value of another type. by referencing the spec . the answer is user model dependent. UML does have a test identity action (11.3.49), but this only tests if two input values .are the same identity.. It is not clear what the semantics of this is when the input values are data values which .do not have identity.. In fUML, the semantics of the test identity action was extended to provide a general equality test in the case of data values (see fUML Specification, 8.6.3), so let.s use that. However, it is not clear how to represent .(PositiveInteger)42. in UML. UML only has built-in literals for the four primitive types defined within the UML standard. Nevertheless, it is possible to give a value specification a type (see 7.3.54 . ValueSpecification is a TypedElement), regardless of what kind of value specification it is. Therefore, one could create a LiteralInteger with a value of 42 and a type of PositiveInteger (presumably there would need to be some constraint that the values of literals of type PositiveInteger are actually positive integers, but I don.t know that there is any way to formally specify this in UML.). In fUML, two literal integers as above evaluate to two integer values, both with the value 42, but one with the type Integer and the other with the type PositiveInteger (see fUML Specification, 8.3.2.2.14 . note that the call .this.getType(.Integer.). only gets the built-in Integer type if no type is given for the literal integer, otherwise it returns the type as given in the model). If these two integer values are input to a test identity action execution, they will, indeed, be considered equal, because the equality test for integer values just tests for equality of values, regardless of the types (see fUML Specification, 8.3.2.2.10). So, interestingly enough, PositiveInteger instances are represented as fUML integer values at execution time, then the answer to the first question is .yes. and the answer to the second question is .no. for fUML. -- Ed From: "Rouquette, Nicolas F" To: Ed Seidewitz , Pete Rivett - Adaptive , Steve Cook CC: "uml2-rtf@omg.org" Date: Wed, 4 Feb 2009 08:48:00 -0800 Subject: RE: [Classes] resolution for 6681 Thread-Topic: [Classes] resolution for 6681 Thread-Index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jAAHxVFgAAC4b0w Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized In reviewing the list of issues in [Classes], I found a cluster that revolve around the distinction Ed made in answering Pete.s questions: In the context of a model, the concept of 42 as a value is an issue of syntactic representation, i.e., a ValueSpecification of some kind. From a runtime perspective, the concept of 42 as a value is an issue of semantic interpretation, i.e., a (runtime) Value of some kind . 8.3.2.2.25 in fUML::Semantics::Classes::Kernel. This distinction is illustrated in figures 54 and 55 in clause 8.3.2.1 (fUML::Semantics::Classes::Kernel) Before we had fUML, the UML had no language to talk about the existence of anything. Now that fUML introduced these concepts, what are we going to do about the list of issues that are difficult to answer without bringing into the discussion runtime properties and capabilities of objects and values? Issue 8450: Default values for ValueSpecification are not specified properly Issue 9225: No notation for associating Exceptions with Operations Issue 9445: Link notation for instance diagrams does not cope with multiple classifiers Issue 9622: the default for a Property should not be inconsistent with its type Issue 9703: Unclear usage of LiteralExpression::type Issue 9705: ValueSpecification::isComputable() Issue 9760: Section: 9.14.2 Issue 9805: Default value types Issue 9822: Section: 7.3.44 Issue 9823: Section: 7 Issue 9887: Optional values and evaluation of defaults Issue 9961: navigating from link to link ends Issue 9962: Subclasses of InstanceSpecification Issue 10824: Units and types are still problematic Issue 10827: Consistency in description of ends owned by associations Issue 11827: UML2 Issue: notation for Literals does not allow for name n Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, February 04, 2009 7:30 AM To: Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 6:39 PM To: Steve Cook Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). [EVS] That.s also the way I tend to think of it. Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. [EVS] I guess I was still stuck in the mode of thinking of owned opposite association ends. It certainly does not make sense for Integer to own an association end. However, if the association end is owned by the association, then it is certainly possible to navigate the association using a read link action, as you indicate. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? [EVS] Well, it is hard to reference the spec to answer your questions, since it is not entirely clear, in terms of the spec, what your questions even mean. However, since Integer is a primitive type, I suppose we could start out with the semantics of PrimitiveType (7.3.43): .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). .Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.. [EVS] I read this as meaning that two instances of the same primitive type with the same representation are indistinguishable (and, in passing, I note that it says they are .indistinguishable., not .the same.). The spec doesn.t say anything about equality of values across different data types. In fact, there is no general semantic concept of .equality. in UML, so you really can.t answer the question .is a value of one type equal to the value of another type. by referencing the spec . the answer is user model dependent. UML does have a test identity action (11.3.49), but this only tests if two input values .are the same identity.. It is not clear what the semantics of this is when the input values are data values which .do not have identity.. In fUML, the semantics of the test identity action was extended to provide a general equality test in the case of data values (see fUML Specification, 8.6.3), so let.s use that. However, it is not clear how to represent .(PositiveInteger)42. in UML. UML only has built-in literals for the four primitive types defined within the UML standard. Nevertheless, it is possible to give a value specification a type (see 7.3.54 . ValueSpecification is a TypedElement), regardless of what kind of value specification it is. Therefore, one could create a LiteralInteger with a value of 42 and a type of PositiveInteger (presumably there would need to be some constraint that the values of literals of type PositiveInteger are actually positive integers, but I don.t know that there is any way to formally specify this in UML.). In fUML, two literal integers as above evaluate to two integer values, both with the value 42, but one with the type Integer and the other with the type PositiveInteger (see fUML Specification, 8.3.2.2.14 . note that the call .this.getType(.Integer.). only gets the built-in Integer type if no type is given for the literal integer, otherwise it returns the type as given in the model). If these two integer values are input to a test identity action execution, they will, indeed, be considered equal, because the equality test for integer values just tests for equality of values, regardless of the types (see fUML Specification, 8.3.2.2.10). So, interestingly enough, PositiveInteger instances are represented as fUML integer values at execution time, then the answer to the first question is .yes. and the answer to the second question is .no. for fUML. -- Ed Subject: RE: [Classes] resolution for 6681 Date: Wed, 4 Feb 2009 11:58:58 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jAAHxVFgAAC4b0wAAJTEvA= From: "Ed Seidewitz" To: "Rouquette, Nicolas F" Cc: Nicolas . This is a darn good question. The lack of a clear underlying semantic model for UML has always made for hand-waving and confusion in the specification and discussion of UML semantics. Talking in terms of fUML really helps clarify such discussions . see my immediately previous further response to Cory, for example. Such clarification is, after all, very much the point of having a precise semantic specification like fUML! Unfortunately, the scope of the fUML semantics is currently limited compared to all of UML (though there is a pretty good coverage of Kernel). And, since the intent of the fUML spec is to formalize a subset of the semantics as already standardized for UML 2, it would be circular to have the UML spec refer back to fUML! So, I would suggest that, where appropriate and helpful, the fUML semantics be used as a guide and vocabulary for discussing semantic issues in the more general UML 2 spec (as I have done response to Pete.s questions). However, when it comes down to actually updating the UML spec itself, any such discussion needs to be .back converted. to traditional UML textual semantic descriptions . and, in many cases, generalized beyond the fUML subset. Any fUML-based discussion could still be recorded in the record of the issue resolution, however. In any case, having some sort of common semantic model to use as a basis for discussion can, I think, help us greatly improve the clarity of the informal semantic descriptions as we resolve some of these issues. (Even though it never got standardized, having such a formal model in the background was one reason the informal semantic specification for actions in UML 1.5 turned out so well!) -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, February 04, 2009 11:48 AM To: Ed Seidewitz; Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 In reviewing the list of issues in [Classes], I found a cluster that revolve around the distinction Ed made in answering Pete.s questions: In the context of a model, the concept of 42 as a value is an issue of syntactic representation, i.e., a ValueSpecification of some kind. From a runtime perspective, the concept of 42 as a value is an issue of semantic interpretation, i.e., a (runtime) Value of some kind . 8.3.2.2.25 in fUML::Semantics::Classes::Kernel. This distinction is illustrated in figures 54 and 55 in clause 8.3.2.1 (fUML::Semantics::Classes::Kernel) Before we had fUML, the UML had no language to talk about the existence of anything. Now that fUML introduced these concepts, what are we going to do about the list of issues that are difficult to answer without bringing into the discussion runtime properties and capabilities of objects and values? Issue 8450: Default values for ValueSpecification are not specified properly Issue 9225: No notation for associating Exceptions with Operations Issue 9445: Link notation for instance diagrams does not cope with multiple classifiers Issue 9622: the default for a Property should not be inconsistent with its type Issue 9703: Unclear usage of LiteralExpression::type Issue 9705: ValueSpecification::isComputable() Issue 9760: Section: 9.14.2 Issue 9805: Default value types Issue 9822: Section: 7.3.44 Issue 9823: Section: 7 Issue 9887: Optional values and evaluation of defaults Issue 9961: navigating from link to link ends Issue 9962: Subclasses of InstanceSpecification Issue 10824: Units and types are still problematic Issue 10827: Consistency in description of ends owned by associations Issue 11827: UML2 Issue: notation for Literals does not allow for name n Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, February 04, 2009 7:30 AM To: Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 6:39 PM To: Steve Cook Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). [EVS] That.s also the way I tend to think of it. Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. [EVS] I guess I was still stuck in the mode of thinking of owned opposite association ends. It certainly does not make sense for Integer to own an association end. However, if the association end is owned by the association, then it is certainly possible to navigate the association using a read link action, as you indicate. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? [EVS] Well, it is hard to reference the spec to answer your questions, since it is not entirely clear, in terms of the spec, what your questions even mean. However, since Integer is a primitive type, I suppose we could start out with the semantics of PrimitiveType (7.3.43): .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). .Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.. [EVS] I read this as meaning that two instances of the same primitive type with the same representation are indistinguishable (and, in passing, I note that it says they are .indistinguishable., not .the same.). The spec doesn.t say anything about equality of values across different data types. In fact, there is no general semantic concept of .equality. in UML, so you really can.t answer the question .is a value of one type equal to the value of another type. by referencing the spec . the answer is user model dependent. UML does have a test identity action (11.3.49), but this only tests if two input values .are the same identity.. It is not clear what the semantics of this is when the input values are data values which .do not have identity.. In fUML, the semantics of the test identity action was extended to provide a general equality test in the case of data values (see fUML Specification, 8.6.3), so let.s use that. However, it is not clear how to represent .(PositiveInteger)42. in UML. UML only has built-in literals for the four primitive types defined within the UML standard. Nevertheless, it is possible to give a value specification a type (see 7.3.54 . ValueSpecification is a TypedElement), regardless of what kind of value specification it is. Therefore, one could create a LiteralInteger with a value of 42 and a type of PositiveInteger (presumably there would need to be some constraint that the values of literals of type PositiveInteger are actually positive integers, but I don.t know that there is any way to formally specify this in UML.). In fUML, two literal integers as above evaluate to two integer values, both with the value 42, but one with the type Integer and the other with the type PositiveInteger (see fUML Specification, 8.3.2.2.14 . note that the call .this.getType(.Integer.). only gets the built-in Integer type if no type is given for the literal integer, otherwise it returns the type as given in the model). If these two integer values are input to a test identity action execution, they will, indeed, be considered equal, because the equality test for integer values just tests for equality of values, regardless of the types (see fUML Specification, 8.3.2.2.10). So, interestingly enough, PositiveInteger instances are represented as fUML integer values at execution time, then the answer to the first question is .yes. and the answer to the second question is .no. for fUML. -- Ed Subject: RE: [Classes] resolution for 6681 Date: Wed, 4 Feb 2009 09:09:17 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 Thread-Index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jAAHxVFgAADjNqgAACu5ZA= From: "Pete Rivett" To: "Cory Casanave" , "Ed Seidewitz" , "Steve Cook" Cc: Cory, I don.t disagree with what you write in principle, but I was trying to go purely from what the UML spec says. And it does refer to copies of datatype instances (which surely must be another datatype instance). And this does correspond to how many runtime engines work. However as per my longer email I.d prefer UML to stay away from storage considerations. You also refer to .the computational system of slots.: where is this documented? Or is it .well known. theory in the same way as tuples that I.m just ignorant of? Again not in the UML spec which describes slots only in reference to InstanceSpecification (as per my longer email of yesterday), though references them in other places. Pete From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 04 February 2009 08:15 To: Ed Seidewitz; Pete Rivett; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 If you accept the semantics that type is a predicate, then 42 satisfies the predicate of both integer and positive integer. There is nothing inconsistent with it satisfying both types. I also don.t think this idea of a .copy of 42. makes any sense. You can have a slot for a number containing 42 or a representation of 42 (as a string or in 32 binary digits) . but I don.t think you can copy something that is purely a value. What we are doing in computer programs is manipulating slots (memory locations) that contain a representation of some value, but, committing to such concepts with respect to the definition of values would be to over-commit that concept to a particular computational system. Within the computational system of slots the difference between 42 (in an integer slot) and 42 (in an unsigned integer slot) is significant only with respect to the slot as a constraint on the values it may contain. The value in the slot is unaffected by (and not owned by) that slot. It can, of course, be hard to conceptualize some of these things without grounding it in a computational system . but it is worth trying. So I would agree with Nicolas that all representations of 42 represent the same individual universally. We should not confuse representations (signs in some terminologies) with the thing being represented. -Cory -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, February 04, 2009 10:30 AM To: Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 6:39 PM To: Steve Cook Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). [EVS] That.s also the way I tend to think of it. Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. [EVS] I guess I was still stuck in the mode of thinking of owned opposite association ends. It certainly does not make sense for Integer to own an association end. However, if the association end is owned by the association, then it is certainly possible to navigate the association using a read link action, as you indicate. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? [EVS] Well, it is hard to reference the spec to answer your questions, since it is not entirely clear, in terms of the spec, what your questions even mean. However, since Integer is a primitive type, I suppose we could start out with the semantics of PrimitiveType (7.3.43): .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). .Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.. [EVS] I read this as meaning that two instances of the same primitive type with the same representation are indistinguishable (and, in passing, I note that it says they are .indistinguishable., not .the same.). The spec doesn.t say anything about equality of values across different data types. In fact, there is no general semantic concept of .equality. in UML, so you really can.t answer the question .is a value of one type equal to the value of another type. by referencing the spec . the answer is user model dependent. UML does have a test identity action (11.3.49), but this only tests if two input values .are the same identity.. It is not clear what the semantics of this is when the input values are data values which .do not have identity.. In fUML, the semantics of the test identity action was extended to provide a general equality test in the case of data values (see fUML Specification, 8.6.3), so let.s use that. However, it is not clear how to represent .(PositiveInteger)42. in UML. UML only has built-in literals for the four primitive types defined within the UML standard. Nevertheless, it is possible to give a value specification a type (see 7.3.54 . ValueSpecification is a TypedElement), regardless of what kind of value specification it is. Therefore, one could create a LiteralInteger with a value of 42 and a type of PositiveInteger (presumably there would need to be some constraint that the values of literals of type PositiveInteger are actually positive integers, but I don.t know that there is any way to formally specify this in UML.). In fUML, two literal integers as above evaluate to two integer values, both with the value 42, but one with the type Integer and the other with the type PositiveInteger (see fUML Specification, 8.3.2.2.14 . note that the call .this.getType(.Integer.). only gets the built-in Integer type if no type is given for the literal integer, otherwise it returns the type as given in the model). If these two integer values are input to a test identity action execution, they will, indeed, be considered equal, because the equality test for integer values just tests for equality of values, regardless of the types (see fUML Specification, 8.3.2.2.10). So, interestingly enough, PositiveInteger instances are represented as fUML integer values at execution time, then the answer to the first question is .yes. and the answer to the second question is .no. for fUML. -- Ed X-IronPort-AV: E=Sophos;i="4.37,380,1231110000"; d="scan'208,217";a="30345931" From: LONJON Antoine To: Cory Casanave , Ed Seidewitz , Pete Rivett - Adaptive , Steve Cook CC: "uml2-rtf@omg.org" Date: Wed, 4 Feb 2009 18:27:56 +0100 Subject: RE: [Classes] resolution for 6681 Thread-Topic: [Classes] resolution for 6681 Thread-Index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jAAHxVFgAADjNqgAAH01KA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US I entirely agree with Cory here. If you accept the semantics that type is a predicate, then 42 satisfies the predicate of both integer and positive integer. There is nothing inconsistent with it satisfying both types. Sure. But .type as a predicate. makes it a particular predicate as its involvement leads to crossing classification layers (the . from set theory). I also don.t think this idea of a .copy of 42. makes any sense. You can have a slot for a number containing 42 or a representation of 42 (as a string or in 32 binary digits) . but I don.t think you can copy something thatt is purely a value. What we are doing in computer programs is manipulating slots (memory locations) that contain a representation of some value, but, committing to such concepts with respect to the definition of values would be to over-commit that concept to a particular computational system. Within the computational system of slots the difference between 42 (in an integer slot) and 42 (in an unsigned integer slot) is significant only with respect to the slot as a constraint on the values it may contain. The value in the slot is unaffected by (and not owned by) that slot. It can, of course, be hard to conceptualize some of these things without grounding it in a computational system . but it is worrth trying. The slot implies indeed a particular encoding of the representation of 42. There is always a kind of encoding for a representation (ASCII, .). As Pete said, UML doesn.t say much about storage/encoding considerations. The good is that it provides specifications at a logical level of concern. The bad is that users tend to twist the notion of data type to incorporate encoding considerations which leads inconsistent data definitions. So I would agree with Nicolas that all representations of 42 represent the same individual universally. We should not confuse representations (signs in some terminologies) with the thing being represented. Sure. This also means that the .thing being represented. may be outside our universe of discourse and that we need a convention to be able to designate it. Cory, Are all these considerations also taken into account in SMOF? (eg fUML) Antoine -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, February 04, 2009 10:30 AM To: Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 6:39 PM To: Steve Cook Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). [EVS] That.s also the way I tend to think of it. Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. [EVS] I guess I was still stuck in the mode of thinking of owned opposite association ends. It certainly does not make sense for Integer to own an association end. However, if the association end is owned by the association, then it is certainly possible to navigate the association using a read link action, as you indicate. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? [EVS] Well, it is hard to reference the spec to answer your questions, since it is not entirely clear, in terms of the spec, what your questions even mean. However, since Integer is a primitive type, I suppose we could start out with the semantics of PrimitiveType (7.3.43): .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). .Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.. [EVS] I read this as meaning that two instances of the same primitive type with the same representation are indistinguishable (and, in passing, I note that it says they are .indistinguishable., not .the same.). The spec doesn.t say anything about equality of values across different data types. In fact, there is no general semantic concept of .equality. in UML, so you really can.t answer the question .is a value of one type equal to the value of another type. by referencing the spec . the answer is user model dependeent. UML does have a test identity action (11.3.49), but this only tests if two input values .are the same identity.. It is not clear what the semantics of this is when the input values are data values which .do not have identity.. In fUML, the semantics of the test identity action was extended to provide a general equality test in the case of data values (see fUML Specification, 8.6.3), so let.s use that. However, it is not clear how to represent .(PositiveInteger)42. in UML. UML only has built-in literals for the four primitive types defined within the UML standard. Nevertheless, it is possible to give a value specification a type (see 7.3.54 . ValueSpecification is a TypedElemment), regardless of what kind of value specification it is. Therefore, one could create a LiteralInteger with a value of 42 and a type of PositiveInteger (presumably there would need to be some constraint that the values of literals of type PositiveInteger are actually positive integers, but I don.t know that there is any way to formally specify this in UML.). In fUML, two literal integers as above evaluate to two integer values, both with the value 42, but one with the type Integer and the other with the type PositiveInteger (see fUML Specification, 8.3.2.2.14 . note that the call .this.gettType(.Integer.). only gets the built-in Integer type if no type is given for the literal integer, otherwise it returns the type as given in the model). If these two integer values are input to a test identity action execution, they will, indeed, be considered equal, because the equality test for integer values just tests for equality of values, regardless of the types (see fUML Specification, 8.3.2.2.10). So, interestingly enough, PositiveInteger instances are represented as fUML integer values at execution time, then the answer to the first question is .yes. and the answer to the second question is .no. for fUML. -- Ed **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended or the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** Subject: RE: [Classes] resolution for 6681 Date: Wed, 4 Feb 2009 12:33:55 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jAAHxVFgAADjNqgAACnPfAAAVuIYA== From: "Cory Casanave" To: "Ed Seidewitz" Cc: Ed- .Such as it is. is, of course, what the RTF is here to interpret and refine. We know that UML is somewhat schizophrenic about what it models . a computational runtime OO machine or something more general. Fortunately fUML is not schizophrenic . it is an OO executable machine interpretation of UML. If we wish UML (not fUML) to evolve to being more general than an execution machine (For modeling in general) we will need to make a set of decisions over time that will clarify that distinction. If, on the other hand, fUML defines UML then that is another choice. What you have described is essentially the .factory. interpretation of a class . it is something that .creates. instances. In the integer case I would argue it is creating representations of values that satisfy the type (which UML calls a data type). Representations do have a 1..n relationship to the identity they represent. Even in most computer languages you can.t .create. 42. In Java you can.t say int answer_value = new int(42). However you can create an object that contains a representation of 42: Integer answer_object = new Integer(42). You can, of course, put a representation of 42 into a compatible slot: int answer_value = 42; or float float_answer = 42; (Capital Integer being an object, while int is a primitive type) So this idea that there are .new instances. of 42 is somewhat unique to UML. It makes sense that the fUML execution machine only deals with representations and this makes sense with respect to the statement in the spec: The run-time instances of a primitive type . which is obviously a runtime machine perspective. However the idea that .int. has runtime .instances. is locked into the OO concept of classes as factories, which is not even the case in many languages. It would be better to separate class (as a factory for instances satisfying a type) and type (as a predicate) in the core of UML and deal with construction or copies of representations in the executable machine (I.m not even convinced that is correct for the executable machine, but that is another thread). So it would be my suggestion that IF it is the intent of the RTF to evolve UML to being more general than an OO execution machine THEN the distinction between type and class/factory as well as the distinction between representation and represented be made consistent as the specification is evolved. Since it is schizophrenic there is a choice of personalities. It may be that we are arguing angels on a pin head, but I think this class/type issue as well as the .runtime. schizophrenia is pervasive in the UML spec. -Cory -------------------------------------------------------------------------------- From: Ed Seidewitz Sent: Wednesday, February 04, 2009 11:46 AM To: Cory Casanave Cc: 'uml2-rtf@omg.org' Subject: RE: [Classes] resolution for 6681 Cory . There is the semantics that one might accept, and the semantics that is actually specified for UML (such as it is.). The semantics for PrimitiveType that I quoted makes a distinction between .data values. that are instances of the type and the .mathematical elements defined outside of UML. represented by those data values. In fact, there is a .many-to-one correspondence. between data values and mathematical elements, which, for integers, would indicate that there can be more than one Integer data value for the same mathematical integer. This is pretty directly reflected in the more precise semantics of fUML. The fUML execution model includes the class IntegerValue, which is a subclass of DataValue (see fUML Spec, 8.3.2). IntegerValue has an attribute .value. of type Integer. The type Integer, as used in the execution model, is to be interpreted with the base semantics of bUML, which maps it to the set of mathematical integers (fUML Spec, 10.3.1.2). So, in fUML, there can, indeed, be more than one IntegerValue with the same mathematical integer value . and, in fact, one is created every time something evaluates to or outputs an integer value. However, these are .indistinguishable. from each other in the sense that any two IntegerValues with the same underlying value are equal and interchangeable. In effect, we have LiteralInteger as the syntactic representation of an integer in UML, IntegerValue as the semantic representation in fUML (which, for integers, is actually isomorphic to the syntactic representation) and both of these are, ultimately, representations of the mathematical concept of an integer. And I agree that every literal integer for 42 and every integer value for 42 represents the same individual mathematical 42 universally. Note that the same kind of interpretation applies for the other standard UML primitive types: Boolean, UnlimitedNatural and String. The case of enumerations and structured data types is a little sticker in fUML, since neither of these kinds of data types is included in bUML, so the fUML spec does not give them a direct base semantics. Nevertheless, in principle one could map instances of enumerations and structured data types to appropriate mathematical elements (e.g., tuples for structured data types) for which the idea of a many-to-one representation of universal individuals would still apply. Of course, there are certainly many ways to think about this, but the above is based on what the spec says . which is what Pete asked for. And rightly so, since, in the RTF, the spec is our baseline. -- Ed -------------------------------------------------------------------------------- From: Cory Casanave Sent: Wednesday, February 04, 2009 11:15 AM To: Ed Seidewitz; Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 If you accept the semantics that type is a predicate, then 42 satisfies the predicate of both integer and positive integer. There is nothing inconsistent with it satisfying both types. I also don.t think this idea of a .copy of 42. makes any sense. You can have a slot for a number containing 42 or a representation of 42 (as a string or in 32 binary digits) . but I don.t think you can copy something that is purely a value. What we are doing in computer programs is manipulating slots (memory locations) that contain a representation of some value, but, committing to such concepts with respect to the definition of values would be to over-commit that concept to a particular computational system. Within the computational system of slots the difference between 42 (in an integer slot) and 42 (in an unsigned integer slot) is significant only with respect to the slot as a constraint on the values it may contain. The value in the slot is unaffected by (and not owned by) that slot. It can, of course, be hard to conceptualize some of these things without grounding it in a computational system . but it is worth trying. So I would agree with Nicolas that all representations of 42 represent the same individual universally. We should not confuse representations (signs in some terminologies) with the thing being represented. -Cory -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, February 04, 2009 10:30 AM To: Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 6:39 PM To: Steve Cook Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). [EVS] That.s also the way I tend to think of it. Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. [EVS] I guess I was still stuck in the mode of thinking of owned opposite association ends. It certainly does not make sense for Integer to own an association end. However, if the association end is owned by the association, then it is certainly possible to navigate the association using a read link action, as you indicate. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? [EVS] Well, it is hard to reference the spec to answer your questions, since it is not entirely clear, in terms of the spec, what your questions even mean. However, since Integer is a primitive type, I suppose we could start out with the semantics of PrimitiveType (7.3.43): .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). .Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.. [EVS] I read this as meaning that two instances of the same primitive type with the same representation are indistinguishable (and, in passing, I note that it says they are .indistinguishable., not .the same.). The spec doesn.t say anything about equality of values across different data types. In fact, there is no general semantic concept of .equality. in UML, so you really can.t answer the question .is a value of one type equal to the value of another type. by referencing the spec . the answer is user model dependent. UML does have a test identity action (11.3.49), but this only tests if two input values .are the same identity.. It is not clear what the semantics of this is when the input values are data values which .do not have identity.. In fUML, the semantics of the test identity action was extended to provide a general equality test in the case of data values (see fUML Specification, 8.6.3), so let.s use that. However, it is not clear how to represent .(PositiveInteger)42. in UML. UML only has built-in literals for the four primitive types defined within the UML standard. Nevertheless, it is possible to give a value specification a type (see 7.3.54 . ValueSpecification is a TypedElement), regardless of what kind of value specification it is. Therefore, one could create a LiteralInteger with a value of 42 and a type of PositiveInteger (presumably there would need to be some constraint that the values of literals of type PositiveInteger are actually positive integers, but I don.t know that there is any way to formally specify this in UML.). In fUML, two literal integers as above evaluate to two integer values, both with the value 42, but one with the type Integer and the other with the type PositiveInteger (see fUML Specification, 8.3.2.2.14 . note that the call .this.getType(.Integer.). only gets the built-in Integer type if no type is given for the literal integer, otherwise it returns the type as given in the model). If these two integer values are input to a test identity action execution, they will, indeed, be considered equal, because the equality test for integer values just tests for equality of values, regardless of the types (see fUML Specification, 8.3.2.2.10). So, interestingly enough, PositiveInteger instances are represented as fUML integer values at execution time, then the answer to the first question is .yes. and the answer to the second question is .no. for fUML. -- Ed Subject: RE: [Classes] resolution for 6681 Date: Wed, 4 Feb 2009 12:45:23 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jAAHxVFgAADjNqgAACu5ZAAAssskA== From: "Cory Casanave" To: "Pete Rivett - Adaptive" , "Ed Seidewitz" , "Steve Cook" Cc: Pete, I think it is clear that we both understand the issues, it is just a matter of deciding how much commitment we want to make at various levels of UML. I am, as usual, trying to purge unnecessary commitment. While there has been quite a bit written about slots as a .well known. concept, I was referring to the way slots are reified in the UML model. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Wednesday, February 04, 2009 12:09 PM To: Cory Casanave; Ed Seidewitz; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Cory, I don.t disagree with what you write in principle, but I was trying to go purely from what the UML spec says. And it does refer to copies of datatype instances (which surely must be another datatype instance). And this does correspond to how many runtime engines work. However as per my longer email I.d prefer UML to stay away from storage considerations. You also refer to .the computational system of slots.: where is this documented? Or is it .well known. theory in the same way as tuples that I.m just ignorant of? Again not in the UML spec which describes slots only in reference to InstanceSpecification (as per my longer email of yesterday), though references them in other places. Pete From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 04 February 2009 08:15 To: Ed Seidewitz; Pete Rivett; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 If you accept the semantics that type is a predicate, then 42 satisfies the predicate of both integer and positive integer. There is nothing inconsistent with it satisfying both types. I also don.t think this idea of a .copy of 42. makes any sense. You can have a slot for a number containing 42 or a representation of 42 (as a string or in 32 binary digits) . but I don.t think you can copy something that is purely a value. What we are doing in computer programs is manipulating slots (memory locations) that contain a representation of some value, but, committing to such concepts with respect to the definition of values would be to over-commit that concept to a particular computational system. Within the computational system of slots the difference between 42 (in an integer slot) and 42 (in an unsigned integer slot) is significant only with respect to the slot as a constraint on the values it may contain. The value in the slot is unaffected by (and not owned by) that slot. It can, of course, be hard to conceptualize some of these things without grounding it in a computational system . but it is worth trying. So I would agree with Nicolas that all representations of 42 represent the same individual universally. We should not confuse representations (signs in some terminologies) with the thing being represented. -Cory -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, February 04, 2009 10:30 AM To: Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 6:39 PM To: Steve Cook Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). [EVS] That.s also the way I tend to think of it. Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. [EVS] I guess I was still stuck in the mode of thinking of owned opposite association ends. It certainly does not make sense for Integer to own an association end. However, if the association end is owned by the association, then it is certainly possible to navigate the association using a read link action, as you indicate. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? [EVS] Well, it is hard to reference the spec to answer your questions, since it is not entirely clear, in terms of the spec, what your questions even mean. However, since Integer is a primitive type, I suppose we could start out with the semantics of PrimitiveType (7.3.43): .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). .Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.. [EVS] I read this as meaning that two instances of the same primitive type with the same representation are indistinguishable (and, in passing, I note that it says they are .indistinguishable., not .the same.). The spec doesn.t say anything about equality of values across different data types. In fact, there is no general semantic concept of .equality. in UML, so you really can.t answer the question .is a value of one type equal to the value of another type. by referencing the spec . the answer is user model dependent. UML does have a test identity action (11.3.49), but this only tests if two input values .are the same identity.. It is not clear what the semantics of this is when the input values are data values which .do not have identity.. In fUML, the semantics of the test identity action was extended to provide a general equality test in the case of data values (see fUML Specification, 8.6.3), so let.s use that. However, it is not clear how to represent .(PositiveInteger)42. in UML. UML only has built-in literals for the four primitive types defined within the UML standard. Nevertheless, it is possible to give a value specification a type (see 7.3.54 . ValueSpecification is a TypedElement), regardless of what kind of value specification it is. Therefore, one could create a LiteralInteger with a value of 42 and a type of PositiveInteger (presumably there would need to be some constraint that the values of literals of type PositiveInteger are actually positive integers, but I don.t know that there is any way to formally specify this in UML.). In fUML, two literal integers as above evaluate to two integer values, both with the value 42, but one with the type Integer and the other with the type PositiveInteger (see fUML Specification, 8.3.2.2.14 . note that the call .this.getType(.Integer.). only gets the built-in Integer type if no type is given for the literal integer, otherwise it returns the type as given in the model). If these two integer values are input to a test identity action execution, they will, indeed, be considered equal, because the equality test for integer values just tests for equality of values, regardless of the types (see fUML Specification, 8.3.2.2.10). So, interestingly enough, PositiveInteger instances are represented as fUML integer values at execution time, then the answer to the first question is .yes. and the answer to the second question is .no. for fUML. -- Ed Subject: RE: [Classes] resolution for 6681 Date: Wed, 4 Feb 2009 12:58:50 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jAAHxVFgAADjNqgAACnPfAAAVuIYAABiZSw From: "Ed Seidewitz" To: "Cory Casanave" Cc: Cory . I have thought for a long time that it is better to separate class and type. However, that separation is not very evident in UML. A class is clearly both a type and a factory (or at least a specification for instantiation) in UML. And I would submit that it is specifically not the intent of this RTF to evolve UML to be more general. The intent of the RTF is to resolve those issues that can be addressed tactically. The type/class distinction you bring up is fundamental (.in the core of UML.), and addressing it would thus seem to be very strategic. Of course, the .schizophrenia. you note in UML often makes it hard to disentangle tactical revisions from needed strategic changes. And in some cases dealing with an issue tactically may make a strategic problem worse . in which case it is fine for us to decide that the issue should be classified as strategic and not addressed right now. But in those cases in which we can interpret the spec reasonably in its own terms, as it currently exists, and remove inconsistencies and ambiguities tactically on that bases, please let.s do so in the short term. Otherwise, the strategic discussions will grow to consume all our time, strategic resolutions will still end up years off, and we will have lost our opportunity and momentum to at least make the situation better in the interim. So far, all this discussion has come from just one resolution proposed by Nicolas in the classes area . which we already pretty much know we want to change on tactical grounds of invalidating common existing models. The class/type distinctions, OO execution bias, improved component modeling . I think these are all great issues to begin discussing in detail when the strategic working group meets in March. -- Ed -------------------------------------------------------------------------------- From: Cory Casanave Sent: Wednesday, February 04, 2009 12:34 PM To: Ed Seidewitz Cc: 'uml2-rtf@omg.org' Subject: RE: [Classes] resolution for 6681 Ed- .Such as it is. is, of course, what the RTF is here to interpret and refine. We know that UML is somewhat schizophrenic about what it models . a computational runtime OO machine or something more general. Fortunately fUML is not schizophrenic . it is an OO executable machine interpretation of UML. If we wish UML (not fUML) to evolve to being more general than an execution machine (For modeling in general) we will need to make a set of decisions over time that will clarify that distinction. If, on the other hand, fUML defines UML then that is another choice. What you have described is essentially the .factory. interpretation of a class . it is something that .creates. instances. In the integer case I would argue it is creating representations of values that satisfy the type (which UML calls a data type). Representations do have a 1..n relationship to the identity they represent. Even in most computer languages you can.t .create. 42. In Java you can.t say int answer_value = new int(42). However you can create an object that contains a representation of 42: Integer answer_object = new Integer(42). You can, of course, put a representation of 42 into a compatible slot: int answer_value = 42; or float float_answer = 42; (Capital Integer being an object, while int is a primitive type) So this idea that there are .new instances. of 42 is somewhat unique to UML. It makes sense that the fUML execution machine only deals with representations and this makes sense with respect to the statement in the spec: The run-time instances of a primitive type . which is obviously a runtime machine perspective. However the idea that .int. has runtime .instances. is locked into the OO concept of classes as factories, which is not even the case in many languages. It would be better to separate class (as a factory for instances satisfying a type) and type (as a predicate) in the core of UML and deal with construction or copies of representations in the executable machine (I.m not even convinced that is correct for the executable machine, but that is another thread). So it would be my suggestion that IF it is the intent of the RTF to evolve UML to being more general than an OO execution machine THEN the distinction between type and class/factory as well as the distinction between representation and represented be made consistent as the specification is evolved. Since it is schizophrenic there is a choice of personalities. It may be that we are arguing angels on a pin head, but I think this class/type issue as well as the .runtime. schizophrenia is pervasive in the UML spec. -Cory -------------------------------------------------------------------------------- From: Ed Seidewitz Sent: Wednesday, February 04, 2009 11:46 AM To: Cory Casanave Cc: 'uml2-rtf@omg.org' Subject: RE: [Classes] resolution for 6681 Cory . There is the semantics that one might accept, and the semantics that is actually specified for UML (such as it is.). The semantics for PrimitiveType that I quoted makes a distinction between .data values. that are instances of the type and the .mathematical elements defined outside of UML. represented by those data values. In fact, there is a .many-to-one correspondence. between data values and mathematical elements, which, for integers, would indicate that there can be more than one Integer data value for the same mathematical integer. This is pretty directly reflected in the more precise semantics of fUML. The fUML execution model includes the class IntegerValue, which is a subclass of DataValue (see fUML Spec, 8.3.2). IntegerValue has an attribute .value. of type Integer. The type Integer, as used in the execution model, is to be interpreted with the base semantics of bUML, which maps it to the set of mathematical integers (fUML Spec, 10.3.1.2). So, in fUML, there can, indeed, be more than one IntegerValue with the same mathematical integer value . and, in fact, one is created every time something evaluates to or outputs an integer value. However, these are .indistinguishable. from each other in the sense that any two IntegerValues with the same underlying value are equal and interchangeable. In effect, we have LiteralInteger as the syntactic representation of an integer in UML, IntegerValue as the semantic representation in fUML (which, for integers, is actually isomorphic to the syntactic representation) and both of these are, ultimately, representations of the mathematical concept of an integer. And I agree that every literal integer for 42 and every integer value for 42 represents the same individual mathematical 42 universally. Note that the same kind of interpretation applies for the other standard UML primitive types: Boolean, UnlimitedNatural and String. The case of enumerations and structured data types is a little sticker in fUML, since neither of these kinds of data types is included in bUML, so the fUML spec does not give them a direct base semantics. Nevertheless, in principle one could map instances of enumerations and structured data types to appropriate mathematical elements (e.g., tuples for structured data types) for which the idea of a many-to-one representation of universal individuals would still apply. Of course, there are certainly many ways to think about this, but the above is based on what the spec says . which is what Pete asked for. And rightly so, since, in the RTF, the spec is our baseline. -- Ed -------------------------------------------------------------------------------- From: Cory Casanave Sent: Wednesday, February 04, 2009 11:15 AM To: Ed Seidewitz; Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 If you accept the semantics that type is a predicate, then 42 satisfies the predicate of both integer and positive integer. There is nothing inconsistent with it satisfying both types. I also don.t think this idea of a .copy of 42. makes any sense. You can have a slot for a number containing 42 or a representation of 42 (as a string or in 32 binary digits) . but I don.t think you can copy something that is purely a value. What we are doing in computer programs is manipulating slots (memory locations) that contain a representation of some value, but, committing to such concepts with respect to the definition of values would be to over-commit that concept to a particular computational system. Within the computational system of slots the difference between 42 (in an integer slot) and 42 (in an unsigned integer slot) is significant only with respect to the slot as a constraint on the values it may contain. The value in the slot is unaffected by (and not owned by) that slot. It can, of course, be hard to conceptualize some of these things without grounding it in a computational system . but it is worth trying. So I would agree with Nicolas that all representations of 42 represent the same individual universally. We should not confuse representations (signs in some terminologies) with the thing being represented. -Cory -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, February 04, 2009 10:30 AM To: Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 6:39 PM To: Steve Cook Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). [EVS] That.s also the way I tend to think of it. Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. [EVS] I guess I was still stuck in the mode of thinking of owned opposite association ends. It certainly does not make sense for Integer to own an association end. However, if the association end is owned by the association, then it is certainly possible to navigate the association using a read link action, as you indicate. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? [EVS] Well, it is hard to reference the spec to answer your questions, since it is not entirely clear, in terms of the spec, what your questions even mean. However, since Integer is a primitive type, I suppose we could start out with the semantics of PrimitiveType (7.3.43): .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). .Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.. [EVS] I read this as meaning that two instances of the same primitive type with the same representation are indistinguishable (and, in passing, I note that it says they are .indistinguishable., not .the same.). The spec doesn.t say anything about equality of values across different data types. In fact, there is no general semantic concept of .equality. in UML, so you really can.t answer the question .is a value of one type equal to the value of another type. by referencing the spec . the answer is user model dependent. UML does have a test identity action (11.3.49), but this only tests if two input values .are the same identity.. It is not clear what the semantics of this is when the input values are data values which .do not have identity.. In fUML, the semantics of the test identity action was extended to provide a general equality test in the case of data values (see fUML Specification, 8.6.3), so let.s use that. However, it is not clear how to represent .(PositiveInteger)42. in UML. UML only has built-in literals for the four primitive types defined within the UML standard. Nevertheless, it is possible to give a value specification a type (see 7.3.54 . ValueSpecification is a TypedElement), regardless of what kind of value specification it is. Therefore, one could create a LiteralInteger with a value of 42 and a type of PositiveInteger (presumably there would need to be some constraint that the values of literals of type PositiveInteger are actually positive integers, but I don.t know that there is any way to formally specify this in UML.). In fUML, two literal integers as above evaluate to two integer values, both with the value 42, but one with the type Integer and the other with the type PositiveInteger (see fUML Specification, 8.3.2.2.14 . note that the call .this.getType(.Integer.). only gets the built-in Integer type if no type is given for the literal integer, otherwise it returns the type as given in the model). If these two integer values are input to a test identity action execution, they will, indeed, be considered equal, because the equality test for integer values just tests for equality of values, regardless of the types (see fUML Specification, 8.3.2.2.10). So, interestingly enough, PositiveInteger instances are represented as fUML integer values at execution time, then the answer to the first question is .yes. and the answer to the second question is .no. for fUML. -- Ed Subject: RE: [Classes] resolution for 6681 Date: Wed, 4 Feb 2009 14:32:18 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Classes] resolution for 6681 thread-index: AcmGKMb30DuxgyN5QY6ndNOdUT+NeAAAOqngAAD5MwAAAIyhcAAAIyzAAAAU+jAAACqAkAADc8TgAAYI8jAAHxVFgAADjNqgAACnPfAAAVuIYAABiZSwAAKnioA= From: "Cory Casanave" To: "Ed Seidewitz" Cc: Ed, The RTF will be making hundreds of decisions and changes. If those decisions are not made with respect to some more consistent state and considered theory I fear the result will be inconsistent and more issues will arise. I am not suggesting wholesale changes, but that we have some idea of where we are going so that the set of changes made are consistent with that direction and, should the opportunity arise, a future version can realize that future state more effectively. UML will be defined by both these hundreds of small changes over time and occasional major revisions. When you have .inconsistencies and ambiguities. you have a choice about what way to make it consistent, I am only suggesting some clarity with respect to how and why one choice may be made over the other. All types are not classes (even in UML) and UML is inconsistent with regard to the treatment of these concepts, choices will be made . understanding where UML specifies types Vs class factories may help achieve consistency. It is the job of the RTF to modify the specification to achieve consistency. If, for example, you take the SET of port related issues you want a SET of resolutions that fit together and, I would hope, provide a more usable result. I can.t imagine that happening if we don.t have some improved idea of what a port is such that the set of resolutions support that improved idea. So while I agree that we should not make wholesale or radical changes or spend undue amounts of time of .strategy., I think direction and intent must be a consideration in the RTF. Since such discussions are common it is also the way the way most RTFs operate in reality. Of course there has to be a balance so that you don.t fall into an analyses paralysis. But, lets not fall into strategic discussions about strategic discussions and get on with it. -Cory -------------------------------------------------------------------------------- From: Ed Seidewitz Sent: Wednesday, February 04, 2009 12:59 PM To: Cory Casanave Cc: 'uml2-rtf@omg.org' Subject: RE: [Classes] resolution for 6681 Cory . I have thought for a long time that it is better to separate class and type. However, that separation is not very evident in UML. A class is clearly both a type and a factory (or at least a specification for instantiation) in UML. And I would submit that it is specifically not the intent of this RTF to evolve UML to be more general. The intent of the RTF is to resolve those issues that can be addressed tactically. The type/class distinction you bring up is fundamental (.in the core of UML.), and addressing it would thus seem to be very strategic. Of course, the .schizophrenia. you note in UML often makes it hard to disentangle tactical revisions from needed strategic changes. And in some cases dealing with an issue tactically may make a strategic problem worse . in which case it is fine for us to decide that the issue should be classified as strategic and not addressed right now. But in those cases in which we can interpret the spec reasonably in its own terms, as it currently exists, and remove inconsistencies and ambiguities tactically on that bases, please let.s do so in the short term. Otherwise, the strategic discussions will grow to consume all our time, strategic resolutions will still end up years off, and we will have lost our opportunity and momentum to at least make the situation better in the interim. So far, all this discussion has come from just one resolution proposed by Nicolas in the classes area . which we already pretty much know we want to change on tactical grounds of invalidating common existing models. The class/type distinctions, OO execution bias, improved component modeling . I think these are all great issues to begin discussing in detail when the strategic working group meets in March. -- Ed -------------------------------------------------------------------------------- From: Cory Casanave Sent: Wednesday, February 04, 2009 12:34 PM To: Ed Seidewitz Cc: 'uml2-rtf@omg.org' Subject: RE: [Classes] resolution for 6681 Ed- .Such as it is. is, of course, what the RTF is here to interpret and refine. We know that UML is somewhat schizophrenic about what it models . a computational runtime OO machine or something more general. Fortunately fUML is not schizophrenic . it is an OO executable machine interpretation of UML. If we wish UML (not fUML) to evolve to being more general than an execution machine (For modeling in general) we will need to make a set of decisions over time that will clarify that distinction. If, on the other hand, fUML defines UML then that is another choice. What you have described is essentially the .factory. interpretation of a class . it is something that .creates. instances. In the integer case I would argue it is creating representations of values that satisfy the type (which UML calls a data type). Representations do have a 1..n relationship to the identity they represent. Even in most computer languages you can.t .create. 42. In Java you can.t say int answer_value = new int(42). However you can create an object that contains a representation of 42: Integer answer_object = new Integer(42). You can, of course, put a representation of 42 into a compatible slot: int answer_value = 42; or float float_answer = 42; (Capital Integer being an object, while int is a primitive type) So this idea that there are .new instances. of 42 is somewhat unique to UML. It makes sense that the fUML execution machine only deals with representations and this makes sense with respect to the statement in the spec: The run-time instances of a primitive type . which is obviously a runtime machine perspective. However the idea that .int. has runtime .instances. is locked into the OO concept of classes as factories, which is not even the case in many languages. It would be better to separate class (as a factory for instances satisfying a type) and type (as a predicate) in the core of UML and deal with construction or copies of representations in the executable machine (I.m not even convinced that is correct for the executable machine, but that is another thread). So it would be my suggestion that IF it is the intent of the RTF to evolve UML to being more general than an OO execution machine THEN the distinction between type and class/factory as well as the distinction between representation and represented be made consistent as the specification is evolved. Since it is schizophrenic there is a choice of personalities. It may be that we are arguing angels on a pin head, but I think this class/type issue as well as the .runtime. schizophrenia is pervasive in the UML spec. -Cory -------------------------------------------------------------------------------- From: Ed Seidewitz Sent: Wednesday, February 04, 2009 11:46 AM To: Cory Casanave Cc: 'uml2-rtf@omg.org' Subject: RE: [Classes] resolution for 6681 Cory . There is the semantics that one might accept, and the semantics that is actually specified for UML (such as it is.). The semantics for PrimitiveType that I quoted makes a distinction between .data values. that are instances of the type and the .mathematical elements defined outside of UML. represented by those data values. In fact, there is a .many-to-one correspondence. between data values and mathematical elements, which, for integers, would indicate that there can be more than one Integer data value for the same mathematical integer. This is pretty directly reflected in the more precise semantics of fUML. The fUML execution model includes the class IntegerValue, which is a subclass of DataValue (see fUML Spec, 8.3.2). IntegerValue has an attribute .value. of type Integer. The type Integer, as used in the execution model, is to be interpreted with the base semantics of bUML, which maps it to the set of mathematical integers (fUML Spec, 10.3.1.2). So, in fUML, there can, indeed, be more than one IntegerValue with the same mathematical integer value . and, in fact, one is created every time something evaluates to or outputs an integer value. However, these are .indistinguishable. from each other in the sense that any two IntegerValues with the same underlying value are equal and interchangeable. In effect, we have LiteralInteger as the syntactic representation of an integer in UML, IntegerValue as the semantic representation in fUML (which, for integers, is actually isomorphic to the syntactic representation) and both of these are, ultimately, representations of the mathematical concept of an integer. And I agree that every literal integer for 42 and every integer value for 42 represents the same individual mathematical 42 universally. Note that the same kind of interpretation applies for the other standard UML primitive types: Boolean, UnlimitedNatural and String. The case of enumerations and structured data types is a little sticker in fUML, since neither of these kinds of data types is included in bUML, so the fUML spec does not give them a direct base semantics. Nevertheless, in principle one could map instances of enumerations and structured data types to appropriate mathematical elements (e.g., tuples for structured data types) for which the idea of a many-to-one representation of universal individuals would still apply. Of course, there are certainly many ways to think about this, but the above is based on what the spec says . which is what Pete asked for. And rightly so, since, in the RTF, the spec is our baseline. -- Ed -------------------------------------------------------------------------------- From: Cory Casanave Sent: Wednesday, February 04, 2009 11:15 AM To: Ed Seidewitz; Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 If you accept the semantics that type is a predicate, then 42 satisfies the predicate of both integer and positive integer. There is nothing inconsistent with it satisfying both types. I also don.t think this idea of a .copy of 42. makes any sense. You can have a slot for a number containing 42 or a representation of 42 (as a string or in 32 binary digits) . but I don.t think you can copy something that is purely a value. What we are doing in computer programs is manipulating slots (memory locations) that contain a representation of some value, but, committing to such concepts with respect to the definition of values would be to over-commit that concept to a particular computational system. Within the computational system of slots the difference between 42 (in an integer slot) and 42 (in an unsigned integer slot) is significant only with respect to the slot as a constraint on the values it may contain. The value in the slot is unaffected by (and not owned by) that slot. It can, of course, be hard to conceptualize some of these things without grounding it in a computational system . but it is worth trying. So I would agree with Nicolas that all representations of 42 represent the same individual universally. We should not confuse representations (signs in some terminologies) with the thing being represented. -Cory -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, February 04, 2009 10:30 AM To: Pete Rivett - Adaptive; Steve Cook Cc: uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, February 03, 2009 6:39 PM To: Steve Cook Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: [Classes] resolution for 6681 I disagree that in UML there is only one instance of the Datatype Integer with value 42: there can be many instances/copies (all of which are equal and identical). [EVS] That.s also the way I tend to think of it. Each of which may be separately compositely .owned.. And included in tuples (which are the semantic basis for Associations). And one could imagine .navigating from 42. by retrieving all tuples with the value 42 in one position and retrieving the values from the other positions. [EVS] I guess I was still stuck in the mode of thinking of owned opposite association ends. It certainly does not make sense for Integer to own an association end. However, if the association end is owned by the association, then it is certainly possible to navigate the association using a read link action, as you indicate. See the email I just sent for more detail. A separate question (OK two questions), which should be answered with reference to the spec: Is the instance of Datatype Integer with value 42 equal and identical to the instance of Datatype PositiveInteger with value 42? Does it matter whether or not PositiveInteger is defined to be a specialization of Integer? [EVS] Well, it is hard to reference the spec to answer your questions, since it is not entirely clear, in terms of the spec, what your questions even mean. However, since Integer is a primitive type, I suppose we could start out with the semantics of PrimitiveType (7.3.43): .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). .Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.. [EVS] I read this as meaning that two instances of the same primitive type with the same representation are indistinguishable (and, in passing, I note that it says they are .indistinguishable., not .the same.). The spec doesn.t say anything about equality of values across different data types. In fact, there is no general semantic concept of .equality. in UML, so you really can.t answer the question .is a value of one type equal to the value of another type. by referencing the spec . the answer is user model dependent. UML does have a test identity action (11.3.49), but this only tests if two input values .are the same identity.. It is not clear what the semantics of this is when the input values are data values which .do not have identity.. In fUML, the semantics of the test identity action was extended to provide a general equality test in the case of data values (see fUML Specification, 8.6.3), so let.s use that. However, it is not clear how to represent .(PositiveInteger)42. in UML. UML only has built-in literals for the four primitive types defined within the UML standard. Nevertheless, it is possible to give a value specification a type (see 7.3.54 . ValueSpecification is a TypedElement), regardless of what kind of value specification it is. Therefore, one could create a LiteralInteger with a value of 42 and a type of PositiveInteger (presumably there would need to be some constraint that the values of literals of type PositiveInteger are actually positive integers, but I don.t know that there is any way to formally specify this in UML.). In fUML, two literal integers as above evaluate to two integer values, both with the value 42, but one with the type Integer and the other with the type PositiveInteger (see fUML Specification, 8.3.2.2.14 . note that the call .this.getType(.Integer.). only gets the built-in Integer type if no type is given for the literal integer, otherwise it returns the type as given in the model). If these two integer values are input to a test identity action execution, they will, indeed, be considered equal, because the equality test for integer values just tests for equality of values, regardless of the types (see fUML Specification, 8.3.2.2.10). So, interestingly enough, PositiveInteger instances are represented as fUML integer values at execution time, then the answer to the first question is .yes. and the answer to the second question is .no. for fUML. -- Ed Subject: Issue 6681: Data types and composition Date: Fri, 13 Feb 2009 15:02:25 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6681: Data types and composition thread-index: AcmOFf1ALTAaqSu7RhSTGTpoVRXrHA== From: "Ed Seidewitz" To: It looks like the resolution to Issue 6681 in the draft ballot still calls for prohibiting aggregation of data types. I think the general consensus of the group was that this would not be a good idea and invalidate common practice. Further the subsequent discussion led (more or less) to the conclusion that a data type can have multiple instances of the same value, and, therefore, that aggregation of data types can make semantic sense. Despite the rather extensive discussion on this issue, I would suggest that the resolution be kept simple. Perhaps something along the lines of the following: Two instances of a data type with the same value may still be considered to be different, but equal. This may not be clear from the semantics of DataType (Subclause 7.3.10), but it is consistent with the semantics of PrimitiveType (Subclause 7.3.43), where it states that .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). (note the .many-to-one correspondence). It is also consistent with the semantics of data values formalized in the Foundation UML specification. Therefore, the use of aggregation can make semantic sense for data types. We can then either close the issue with no change, or, perhaps, revise the semantics under 7.3.10 to be clearer, by changing the phrase .the same instance. at the end of the first sentence of the second paragraph under Semantics to .indistinguishable., and, in the following sentence, changing .the same. to .equal.. What do you think, Nicolas? If the resolution stands in its current form, I would have to vote against it. -- Ed From: "Rouquette, Nicolas F" To: Ed Seidewitz , "uml2-rtf@omg.org" Date: Fri, 13 Feb 2009 14:46:57 -0800 Subject: RE: Issue 6681: Data types and composition Thread-Topic: Issue 6681: Data types and composition Thread-Index: AcmOFf1ALTAaqSu7RhSTGTpoVRXrHAAFlsFw Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Thanks Ed for the suggestion. I have updated the resolution using a combination of your suggestions and Pete.s earlier analysis. The short answer is yes. The attached revision is checked in SVN. n Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Friday, February 13, 2009 12:02 PM To: uml2-rtf@omg.org Subject: Issue 6681: Data types and composition It looks like the resolution to Issue 6681 in the draft ballot still calls for prohibiting aggregation of data types. I think the general consensus of the group was that this would not be a good idea and invalidate common practice. Further the subsequent discussion led (more or less) to the conclusion that a data type can have multiple instances of the same value, and, therefore, that aggregation of data types can make semantic sense. Despite the rather extensive discussion on this issue, I would suggest that the resolution be kept simple. Perhaps something along the lines of the following: Two instances of a data type with the same value may still be considered to be different, but equal. This may not be clear from the semantics of DataType (Subclause 7.3.10), but it is consistent with the semantics of PrimitiveType (Subclause 7.3.43), where it states that .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). (note the .many-to-one correspondence). It is also consistent with the semantics of data values formalized in the Foundation UML specification. Therefore, the use of aggregation can make semantic sense for data types. We can then either close the issue with no change, or, perhaps, revise the semantics under 7.3.10 to be clearer, by changing the phrase .the same instance. at the end of the first sentence of the second paragraph under Semantics to .indistinguishable., and, in the following sentence, changing .the same. to .equal.. What do you think, Nicolas? If the resolution stands in its current form, I would have to vote against it. -- Ed UML 2.3 Classes 6681 Rouquette1.doc Subject: RE: Issue 6681: Data types and composition Date: Fri, 13 Feb 2009 18:54:50 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6681: Data types and composition thread-index: AcmOFf1ALTAaqSu7RhSTGTpoVRXrHAAFlsFwAAJ/hlA= From: "Ed Seidewitz" To: "Rouquette, Nicolas F" Cc: Nicolas . This looks good to me. I think the protocol is still for you to make the update directly in the draft ballot, if you haven.t already done that. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, February 13, 2009 5:47 PM To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Issue 6681: Data types and composition Thanks Ed for the suggestion. I have updated the resolution using a combination of your suggestions and Pete.s earlier analysis. The short answer is yes. The attached revision is checked in SVN. n Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Friday, February 13, 2009 12:02 PM To: uml2-rtf@omg.org Subject: Issue 6681: Data types and composition It looks like the resolution to Issue 6681 in the draft ballot still calls for prohibiting aggregation of data types. I think the general consensus of the group was that this would not be a good idea and invalidate common practice. Further the subsequent discussion led (more or less) to the conclusion that a data type can have multiple instances of the same value, and, therefore, that aggregation of data types can make semantic sense. Despite the rather extensive discussion on this issue, I would suggest that the resolution be kept simple. Perhaps something along the lines of the following: Two instances of a data type with the same value may still be considered to be different, but equal. This may not be clear from the semantics of DataType (Subclause 7.3.10), but it is consistent with the semantics of PrimitiveType (Subclause 7.3.43), where it states that .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). (note the .many-to-one correspondence). It is also consistent with the semantics of data values formalized in the Foundation UML specification. Therefore, the use of aggregation can make semantic sense for data types. We can then either close the issue with no change, or, perhaps, revise the semantics under 7.3.10 to be clearer, by changing the phrase .the same instance. at the end of the first sentence of the second paragraph under Semantics to .indistinguishable., and, in the following sentence, changing .the same. to .equal.. What do you think, Nicolas? If the resolution stands in its current form, I would have to vote against it. -- Ed From: "Rouquette, Nicolas F" To: Ed Seidewitz CC: "uml2-rtf@omg.org" Date: Fri, 13 Feb 2009 16:28:11 -0800 Subject: RE: Issue 6681: Data types and composition Thread-Topic: Issue 6681: Data types and composition Thread-Index: AcmOFf1ALTAaqSu7RhSTGTpoVRXrHAAFlsFwAAJ/hlAAAS4EEA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Thanks, I updated the draft ballot in SVN . Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Friday, February 13, 2009 3:55 PM To: Rouquette, Nicolas F Cc: uml2-rtf@omg.org Subject: RE: Issue 6681: Data types and composition Nicolas . This looks good to me. I think the protocol is still for you to make the update directly in the draft ballot, if you haven.t already done that. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, February 13, 2009 5:47 PM To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Issue 6681: Data types and composition Thanks Ed for the suggestion. I have updated the resolution using a combination of your suggestions and Pete.s earlier analysis. The short answer is yes. The attached revision is checked in SVN. n Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Friday, February 13, 2009 12:02 PM To: uml2-rtf@omg.org Subject: Issue 6681: Data types and composition It looks like the resolution to Issue 6681 in the draft ballot still calls for prohibiting aggregation of data types. I think the general consensus of the group was that this would not be a good idea and invalidate common practice. Further the subsequent discussion led (more or less) to the conclusion that a data type can have multiple instances of the same value, and, therefore, that aggregation of data types can make semantic sense. Despite the rather extensive discussion on this issue, I would suggest that the resolution be kept simple. Perhaps something along the lines of the following: Two instances of a data type with the same value may still be considered to be different, but equal. This may not be clear from the semantics of DataType (Subclause 7.3.10), but it is consistent with the semantics of PrimitiveType (Subclause 7.3.43), where it states that .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). (note the .many-to-one correspondence). It is also consistent with the semantics of data values formalized in the Foundation UML specification. Therefore, the use of aggregation can make semantic sense for data types. We can then either close the issue with no change, or, perhaps, revise the semantics under 7.3.10 to be clearer, by changing the phrase .the same instance. at the end of the first sentence of the second paragraph under Semantics to .indistinguishable., and, in the following sentence, changing .the same. to .equal.. What do you think, Nicolas? If the resolution stands in its current form, I would have to vote against it. -- Ed Subject: RE: Issue 6681: Data types and composition Date: Sat, 14 Feb 2009 11:32:41 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6681: Data types and composition Thread-Index: AcmOFf1ALTAaqSu7RhSTGTpoVRXrHAAFlsFwACrrWOA= From: "Pete Rivett" To: "Rouquette, Nicolas F" , "Ed Seidewitz" , The new text seems OK to me, though we should at some stage revisit whether UML should deal at all with storage-related issues (I guess that falls under .strategic.). At the moment storage is mentioned in a few places but overall it.s pretty half-hearted (if that). However I.m not sure if it fully answers the original question: the resolution states: A datatype instance may consume some storage in which case the concept of aggregation may be useful to clarify the storage management implications of a datatype property to its owning classifier. However it does not provide clarity for the shared aggregation case (the text quoted does deal with the composite aggregation case). What would be the difference in storage management implications between shared and no aggregation? If there is no difference (based on the spec which may require a further update) then the answer to the original question is .Only if it is a composition.. By .may require a further update. I mean section 7.3.2 for semantics of shared aggregation which is utterly useless consisting solely of .Indicates that the property has a shared aggregation.. (duh!). But that.s arguably a different Issue. Pete From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 13 February 2009 14:47 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Issue 6681: Data types and composition Thanks Ed for the suggestion. I have updated the resolution using a combination of your suggestions and Pete.s earlier analysis. The short answer is yes. The attached revision is checked in SVN. n Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Friday, February 13, 2009 12:02 PM To: uml2-rtf@omg.org Subject: Issue 6681: Data types and composition It looks like the resolution to Issue 6681 in the draft ballot still calls for prohibiting aggregation of data types. I think the general consensus of the group was that this would not be a good idea and invalidate common practice. Further the subsequent discussion led (more or less) to the conclusion that a data type can have multiple instances of the same value, and, therefore, that aggregation of data types can make semantic sense. Despite the rather extensive discussion on this issue, I would suggest that the resolution be kept simple. Perhaps something along the lines of the following: Two instances of a data type with the same value may still be considered to be different, but equal. This may not be clear from the semantics of DataType (Subclause 7.3.10), but it is consistent with the semantics of PrimitiveType (Subclause 7.3.43), where it states that .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). (note the .many-to-one correspondence). It is also consistent with the semantics of data values formalized in the Foundation UML specification. Therefore, the use of aggregation can make semantic sense for data types. We can then either close the issue with no change, or, perhaps, revise the semantics under 7.3.10 to be clearer, by changing the phrase .the same instance. at the end of the first sentence of the second paragraph under Semantics to .indistinguishable., and, in the following sentence, changing .the same. to .equal.. What do you think, Nicolas? If the resolution stands in its current form, I would have to vote against it. -- Ed From: "Rouquette, Nicolas F" To: Pete Rivett , Ed Seidewitz , "uml2-rtf@omg.org" Date: Sat, 14 Feb 2009 19:04:27 -0800 Subject: RE: Issue 6681: Data types and composition Thread-Topic: Issue 6681: Data types and composition Thread-Index: AcmOFf1ALTAaqSu7RhSTGTpoVRXrHAAFlsFwACrrWOAAAlQOsA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Would this work: A datatype instance may consume some storage in which case the concept of aggregation may be useful to clarify the storage management implications of a datatype property to its owning classifier in the composite aggregation case. The storage management is also relevant to the shared aggregation case by virtue of the fact that the distinction between composite and shared aggregation is subsumed by the precise semantics of shared aggregation which is explicitly acknowledged as a semantic variation point. Nicolas. From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Saturday, February 14, 2009 11:33 AM To: Rouquette, Nicolas F; Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Issue 6681: Data types and composition The new text seems OK to me, though we should at some stage revisit whether UML should deal at all with storage-related issues (I guess that falls under .strategic.). At the moment storage is mentioned in a few places but overall it.s pretty half-hearted (if that). However I.m not sure if it fully answers the original question: the resolution states: A datatype instance may consume some storage in which case the concept of aggregation may be useful to clarify the storage management implications of a datatype property to its owning classifier. However it does not provide clarity for the shared aggregation case (the text quoted does deal with the composite aggregation case). What would be the difference in storage management implications between shared and no aggregation? If there is no difference (based on the spec which may require a further update) then the answer to the original question is .Only if it is a composition.. By .may require a further update. I mean section 7.3.2 for semantics of shared aggregation which is utterly useless consisting solely of .Indicates that the property has a shared aggregation.. (duh!). But that.s arguably a different Issue. Pete From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 13 February 2009 14:47 To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Issue 6681: Data types and composition Thanks Ed for the suggestion. I have updated the resolution using a combination of your suggestions and Pete.s earlier analysis. The short answer is yes. The attached revision is checked in SVN. n Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Friday, February 13, 2009 12:02 PM To: uml2-rtf@omg.org Subject: Issue 6681: Data types and composition It looks like the resolution to Issue 6681 in the draft ballot still calls for prohibiting aggregation of data types. I think the general consensus of the group was that this would not be a good idea and invalidate common practice. Further the subsequent discussion led (more or less) to the conclusion that a data type can have multiple instances of the same value, and, therefore, that aggregation of data types can make semantic sense. Despite the rather extensive discussion on this issue, I would suggest that the resolution be kept simple. Perhaps something along the lines of the following: Two instances of a data type with the same value may still be considered to be different, but equal. This may not be clear from the semantics of DataType (Subclause 7.3.10), but it is consistent with the semantics of PrimitiveType (Subclause 7.3.43), where it states that .The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers). (note the .many-to-one correspondence). It is also consistent with the semantics of data values formalized in the Foundation UML specification. Therefore, the use of aggregation can make semantic sense for data types. We can then either close the issue with no change, or, perhaps, revise the semantics under 7.3.10 to be clearer, by changing the phrase .the same instance. at the end of the first sentence of the second paragraph under Semantics to .indistinguishable., and, in the following sentence, changing .the same. to .equal.. What do you think, Nicolas? If the resolution stands in its current form, I would have to vote against it. -- Ed value types, (Data Type and subtypes)?