Issue 5979: The description of DataType is plainly wrong in the specification (uml2-superstructure-ftf) Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Resolution: see above - resolved Revised Text: Actions taken: June 19, 2003: received issue March 8, 2005: closed issue Discussion: Superstructure Resolution The following changes need to be made to the Superstructure document: ?? Replace 7.12.1 with: 7.12.1 DataType (from Kernel) Description A data type is a type whose instances are identified only by their value. A DataType may contain attributes to support the modeling of structured data types. A typical use of data types would be to represent programming language primitive types or CORBA basic types. For example, integer and string types are often treated as data types. Attributes No additional attributes. Associations • ownedAttribute: Attribute[*] The Attributes owned by the DataType. Subsets Classifier::attribute and Element::ownedMember. • ownedOperation: Operation[*] The Operations owned by the DataType. Subsets Classifier::feature and Element::ownedMember. Constraints No additional constraints. Semantics A data type is a special kind of classifier, similar to a class. It differs from a class in that instances of a data type are identified only by their value. 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 has attributes (i.e. is a structured data type) are considered the be the same if the structure is the same and the values of the corresponding attributes are the same. If a data type has attributes, then instances of that data type will contain attribute values matching the attributes. Semantic Variation Points Any restrictions on the capabilities of data types, such as constraining the types of their attributes, is a semantic variation point. Notation A data type is shown using the classifier symbol with keyword «dataType» or, when it is referenced by e.g. an attribute, shown as a string containing the name of the data type. Examples Figure 41 - Notation of data type: to the left is an icon denoting a data type and to the right is a reference to a data type which is used in an attribute. ?? Move all the Style Guidelines for DataType including the heading from page 96 and insert in place of the current heading for StyleGuidelines of Classifier (on top of page 65) Infrastructure Resolution The following changes need to be made to the Infrastructure document: ?? Replace entire section 11.5.1 with: 11.5.1 DataType (as specialized) Description A data type is a type whose instances are identified only by their value. A DataType may contain attributes to support the modeling of structured data types. A typical use of data types would be to represent programming language primitive types or CORBA basic types. For example, integer and string types are often treated as data types. Attributes No additional attributes. Associations • ownedAttribute: Attribute[*] The Attributes owned by the DataType. Subsets Classifier::attribute and Element::ownedMember. • ownedOperation: Operation[*] The Operations owned by the DataType. Subsets Classifier::feature and Element::ownedMember. Constraints No additional constraints. Semantics A data type is a special kind of classifier, similar to a class. It differs from a class in that instances of a data type are identified only by their value. 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 has attributes (i.e. is a structured data type) are considered the be the same if the structure is the same and the values of the corresponding attributes are the same. If a data type has attributes, then instances of that data type will contain attribute values matching the attributes. Semantic Variation Points Any restrictions on the capabilities of data types, such as constraining the types of their attributes, is a semantic variation point. Notation A data type is shown using the classifier symbol with keyword «dataType» or, when it is referenced by e.g. an attribute, shown as a string containing the name of the data type. Examples Figure 41 - Notation of data type: to the left is an icon denoting a data type and to the right is a reference to a data type which is used in an attribute. ?? Move all the Style Guidelines for DataType including the heading from the bottom of page 134 and insert in place of the current heading for StyleGuidelines of “Classifier (additional properties)” (section 11.3.3) at the bottom of page 121 End of Annotations:===== From: "Baisley, Donald E" To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Cc: James Odell Subject: UML 2 Issues Date: Thu, 19 Jun 2003 19:48:10 -0500 X-Mailer: Internet Mail Service (5.5.2656.59) While reviewing certification questions, I found the following issues in the UML 2 specification. 4. The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data To: "Tolbert, Doug M" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 6 Aug 2004 08:14:59 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/06/2004 08:15:01, Serialize complete at 08/06/2004 08:15:01 I think that this one is safe to put on Ballot 22. Bran "Tolbert, Doug M" 08/05/2004 07:26 PM To Branislav Selic/Ottawa/IBM@IBMCA cc , Subject ,cl, Proposed closure (defer) for shared issue 5979 OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. To: Branislav Selic Cc: "Tolbert, Doug M" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 6 Aug 2004 09:06:47 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/06/2004 09:06:48, Serialize complete at 08/06/2004 09:06:48 On reflection, I will not put this on ballot 22, since the resolution text includes a very strong and possibly controversial opinion indicating that the spec is in error. Furthermore, after stating that opinion, it does not say at all why the issue should be deferred. So, I would like the FTF to have an opportunity to discuss this -- if they are interested. As a guide, the issue centers around the meaning of the word "identity"; i.e., do values have identity or not? (My personal contention is that it all depends on how you define identity and this discussion has philosophers pulling each other's beards. See, for instance, http://plato.stanford.edu/entries/qt-idind/ My recommendation is to defer this issue until the philosophers have sorted out what "identity" means. Alternatively, we can use the common fuzzy meaning of that term in OO circles -- which, in essence, implies physical separateness -- in which case the discussion contained in the resolution proposal is controversial, to say the least.) Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Branislav Selic/Ottawa/IBM@IBMCA 08/06/2004 08:14 AM To "Tolbert, Doug M" cc mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject Re: ,cl, Proposed closure (defer) for shared issue 5979 I think that this one is safe to put on Ballot 22. Bran "Tolbert, Doug M" 08/05/2004 07:26 PM To Branislav Selic/Ottawa/IBM@IBMCA cc , Subject ,cl, Proposed closure (defer) for shared issue 5979 OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Aug 2004 08:05:58 -0700 To: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 I'm drafting a message on this, but don't have time right now to complete it. I feel we can resolve this now. Does anyone feel that Don is wrong? Or that we don't need to be clear on this? If we do vote to defer, do we want to add a Discussion: Summary of how the issue was proposed to be resolved and/or why it wasn't? I think that this one is safe to put on Ballot 22. OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Date: Fri, 6 Aug 2004 09:50:01 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Proposed closure (defer) for shared issue 5979 Thread-Index: AcR7ymHKLB5JtAx+RKCJmUqUhIrSBwACulCw From: "Karl Frank" To: "Joaquin Miller" , , X-OriginalArrivalTime: 06 Aug 2004 16:50:03.0202 (UTC) FILETIME=[6B524220:01C47BD5] I believe this issue can and should be resolved in this FTF and that Don's views are correct. - Karl -------------------------------------------------------------------------------- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Friday, 06 August, 2004 11:06 AM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 I'm drafting a message on this, but don't have time right now to complete it. I feel we can resolve this now. Does anyone feel that Don is wrong? Or that we don't need to be clear on this? If we do vote to defer, do we want to add a Discussion: Summary of how the issue was proposed to be resolved and/or why it wasn't? I think that this one is safe to put on Ballot 22. OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Date: Fri, 6 Aug 2004 14:09:36 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Proposed closure (defer) for shared issue 5979 Thread-Index: AcR73c+prYjW1Y9YQ0agbnNpFgBeYAAGpQYA From: "Tolbert, Doug M" To: "Joaquin Miller" , , X-OriginalArrivalTime: 06 Aug 2004 21:09:36.0973 (UTC) FILETIME=[AE031FD0:01C47BF9] I am merely the shepard of this one, but I will offer up the relevant discussion that has gone into it so far for your consideration. At this point, Don (as of Thursday) does not seem to want to put too much more time into a rewrite and was willing to live with a "defer". I've included his most recent suggested rewrite along with Bran's comments about its appropriateness. Suggestions are welcome, but time is short. From Don (I've excluded some of his text wrt the glossary since it is no more): In both the Infrastructure and Superstructure specifications, for each heading below, please replace the current gibberish with the new text given below (which is hopefully better gibberish). In Core::Constructs DataType A data type is a classifier whose extension is fixed and whose instances, called data values, have a fixed representation. Data types are often used to classify mathematical values, lexical things such as characters, and enumerated things. Description Constructs::DataType specializes DataType from Basic. It also specializes Constructs::Classifier. A data type can have attributes. Each attribute of a data type is unchangeable. For example, if a data type called X-Y-Coordinate has attributes X and Y, the value of X for an X-Y-Coordinate cannot change . having a different X would necessarily imply a different instance of X-Y-Coordinate. An operation on a data type is a pure function . it can return a data value but cannot change a data value. Semantics A data type is a classification of data values. The instances of a data type are fixed. ========== (end of Don's suggested closure) ========= Bran's comments (dated 7/30/04) follow: Hi Doug, Don may be right about what is there being gibberish, but the description that he provides is as terse and cryptic as the pronouncements of a Delphic oracle. My guess is that more people will be confused by this new specification than by the old one, with all of the shortcomings of the latter. Most people with an OO background have at least an intuition as to what "identity" means, even if they are unable to articulate the notion in a precise way. However, when Don says that an "attribute of a data type is unchangeable", my guess is that most people will incorrectly assume that it means that data structures in UML cannot be written. (I realize that is not what he is saying, but that is how it will be read.) In my view, this is a tricky area that enters into some deep philosophical issues that have never been pinned down comprehensively (the whole notion of "value" is quite vague because they represent abstractions in most cases). I don't think we are in a position to resolve those issues. My suggestion is to leave this as is. BTW, if Don wants to keep working on it, please tell him that the Glossary is gone and he does not need to provide changes for that part of the spec. Regards, Bran ======== (end of Bran's comments) ============= Maybe something longer will make Bran happier? You guys figure it out; I'll do the paperwork :-). Doug -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Friday, August 06, 2004 8:06 AM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 I'm drafting a message on this, but don't have time right now to complete it. I feel we can resolve this now. Does anyone feel that Don is wrong? Or that we don't need to be clear on this? If we do vote to defer, do we want to add a Discussion: Summary of how the issue was proposed to be resolved and/or why it wasn't? I think that this one is safe to put on Ballot 22. OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer From: "Thomas Weigert" To: "Karl Frank" , "Joaquin Miller" , , Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Date: Fri, 6 Aug 2004 22:31:03 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Of course Don is wrong. What the spec is saying is that you cannot differentiate between two instances of a data type. E.g., if you have an integer "2" and another integer "2", they are in no way differentiable. In that way, it is said that they have no identity, in that each instance of "2" is exactly like any other. This is different between instances of classes. Even if they have exactly the same values in all their slots, you can tell them apart. For example, in Lisp or Smalltalk there are two comparison operators, "eq" and "equal" (actually, in Lisp there is also "eql", but never mind). Two different objects would never be "eq" even if they are "equal", while two integers that are "equal" are also "eq". In computer science, we usually refer to this difference as that of "identity". So for one, Don does not seem to be familiar with standard computer science terminology. Other things that Don said are incorrect also, e.g., "And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value." But that is precisely the difference between Datatype and Class. You cannot differentiate two occurrences of the same value. Now, of course, it could be the case that we don't want that to be the definition of Datatype, and mean some totally different concept, but then somebody better come along and tell us what that is. However, there are other problems with Datatype. The description section is inconsistent with the actual definition and the semantics. The semantics does not state the constraints implied by the Description section; actually, the definition says that any such constraints are semantic variation points. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, August 06, 2004 11:50 AM To: Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I believe this issue can and should be resolved in this FTF and that Don's views are correct. - Karl -------------------------------------------------------------------------------- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Friday, 06 August, 2004 11:06 AM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 I'm drafting a message on this, but don't have time right now to complete it. I feel we can resolve this now. Does anyone feel that Don is wrong? Or that we don't need to be clear on this? If we do vote to defer, do we want to add a Discussion: Summary of how the issue was proposed to be resolved and/or why it wasn't? I think that this one is safe to put on Ballot 22. OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Aug 2004 11:10:06 -0700 To: MOF UML Infrastructure FTF , UML Superstructure FTF From: Joaquin Miller Subject: ,cl, Issue 5979--Proposed closure The attachment is a proposal for a change in the text at 7.12.1 DataType. The proposed new text is at the beginning of the document, under the heading: Minimal rewrite to resolve issue, while accommodating different theories. I believe the text resolves the issue and does not offend any of the held positions on the issue. If there is agreement on this, i will prepare a resolution including editing instructions. .................... Separate from this issue, there may be a contradiction in the text. The Description says operations of a data type are pure functions. This is not mentioned in the Semantics. In case we wish to consider this at this time, i have drafted alternative texts. These are in the attachment under the headings, Rewrite: Pure functions and Rewrite: Semantic variation. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Issue 5979 Section 7.12.1.doc Issue 5879 Minimal rewrite to resolve issue, while accommodating different theories. 7.12.1 DataType (from Kernel) A data type is a type whose instances are not objects. Data types include primitive built-in types (such as integer and string) as well as enumeration types. Description DataType defines a kind of classifier in which operations are all pure functions (i.e., they can return data values but they cannot change data values). For example, an add operation on a number with another number as an argument returns a number as a result and the target and argument are unchanged. A DataType may contain attributes to support the modeling of structured data types. Attributes No additional attributes. Associations . ownedAttribute: Attribute[*] The Attributes owned by the DataType. Subsets Classifier::attribute and Element:: ownedMember. . ownedOperation: Operation[*] The Operations owned by the DataType. Subsets Classifier::feature and Element:: ownedMember. Constraints No additional constraints. Semantics A data type is a special kind of classifier, similar to a class, whose instances are not objects. For example, integer and string types are often treated as data types. Usually, a data type is used for specification of the type of an attribute. If a data type has attributes, then instances of that data type will contain attribute values matching the attributes. Semantic Variation Points Any restrictions on the capabilities of data types, such as constraining the types of their attributes, is a semantic variation point. Notation A data type is shown using the classifier symbol with keyword «dataType» or, when it is referenced by e.g. an attribute, shown as a string containing the name of the data type. Presentation Options The attribute compartment is often suppressed, especially when a data type does not contain attributes. The operation compartment may be suppressed. A separator line is not drawn for a missing compartment. If a compartment is suppressed, no inference can be drawn about the presence or absence of elements in it. Compartment names can be used to remove ambiguity, if necessary. Additional compartments may be supplied to show other predefined or user-defined model properties (for example, to show business rules, responsibilities, variations, events handled, exceptions raised, and so on). Most compartments are simply lists of strings, although more complicated formats are also possible. Appearance of each compartment should preferably be implicit based on its contents. Compartment names may be used, if needed. A data-type symbol with a stereotype icon may be .collapsed. to show just the stereotype icon, with the name of the data type either inside the rectangle or below the icon. Other contents of the data type are suppressed. Style Guidelines . Center the name of the data type in boldface. . Center keyword (including stereotype names) in plain face within guillemets above data-type name. . For those languages that distinguish between uppercase and lowercase characters, capitalize names (i.e, begin them with an uppercase character). . Left justify attributes and operations in plain face. . Begin attribute and operation names with a lowercase letter. . Show full attributes and operations when needed and suppress them in other contexts or references Examples Figure 41 - Notation of data type: to the left is an icon denoting a data type and to the right is a reference to a data type which is used in an attribute. Rewrite: Pure functions 7.12.1 DataType (from Kernel) A data type is a type whose instances are not objects. Data types include primitive built-in types (such as integer and string) as well as enumeration types. Description DataType defines a kind of classifier in which operations are all pure functions (i.e., they can return data values but they cannot change data values). For example, an add operation on a number with another number as an argument yields a third number as a result; the target and argument are unchanged. A DataType may contain attributes to support the modeling of structured data types. Semantics A data type is a special kind of classifier, similar to a class, whose instances are not objects. For example, integer and string types are often treated as data types. All operations of a data type are pure functions (i.e., they can return data values but they cannot change data values). Usually, a data type is used for specification of the type of an attribute. An enumeration type is a user-definable type comprising a finite number of values. If a data type has attributes, then instances of that data type will contain attribute values matching the attributes. Semantic Variation Points Any restrictions on the capabilities of data types, such as constraining the types of their attributes, is a semantic variation point. Rewrite: Semantic variation 7.12.1 DataType (from Kernel) A data type is a type whose instances are not objects. Data types include primitive built-in types (such as integer and string) as well as enumeration types. Description A data type is a type whose instances are not objects. A DataType may contain attributes to support the modeling of structured data types. Semantics A data type is a special kind of classifier, similar to a class, whose instances are not objects. For example, integer and string types are often treated as data types. Usually, a data type is used for specification of the type of an attribute. If a data type has attributes, then instances of that data type will contain attribute values matching the attributes. Semantic Variation Points Any restrictions on the capabilities of data types, such as constraining the types of their attributes, is a semantic variation point. In particular, whether operations of a data type are all pure functions (i.e., they can return data values but they cannot change data values) is a semantic variation point. For example, in one variation, operations of a number data type are pure functions, an add operation on a number with another number as an argument returns a number as a result and the target and argument are unchanged. In another variation, those operations are not pure functions, an add operation on a number with another number as an argument might change one of the numbers. From: "Thomas Weigert" To: "Joaquin Miller" , "MOF UML Infrastructure FTF" , "UML Superstructure FTF" Subject: RE: ,cl, Issue 5979--Proposed closure Date: Mon, 9 Aug 2004 13:19:24 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Joaquin, defining a data type by "type whose instances are not objects" won't work, as we have not defined what an object is. I think you need to say something positive about what a data type is, or defer the issue. On the pure functions, I think this was trying to express the thought that if you cannot identify different instances, than every function would create new instances. In a sense, an update to a data type attribute would be creating a new data type which differs from the old one by that attribute. As the data types have no identity (or in Don's word, are identified by their value), that new instance is a different instance of the previous one. I think this pure function talk is clumsy, but I understand what the writer was trying to say. However, as this is not in the semantics, it does not really exist (I think the description was just trying to explain the concept). Th. > -----Original Message----- > From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] > Sent: Monday, August 09, 2004 1:10 PM > To: MOF UML Infrastructure FTF; UML Superstructure FTF > Subject: ,cl, Issue 5979--Proposed closure > > > The attachment is a proposal for a change in the text at 7.12.1 > DataType. The proposed new text is at the beginning of the > document, under > the heading: Minimal rewrite to resolve issue, while accommodating > different theories. > > I believe the text resolves the issue and does not offend any of the held > positions on the issue. If there is agreement on this, i will prepare a > resolution including editing instructions. > > .................... > > Separate from this issue, there may be a contradiction in the text. The > Description says operations of a data type are pure functions. > This is not > mentioned in the Semantics. > > In case we wish to consider this at this time, i have drafted alternative > texts. These are in the attachment under the headings, Rewrite: Pure > functions and Rewrite: Semantic variation. > > Cordially, Joaquin > > > > PGP Fingerprint: > CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 > Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Aug 2004 18:10:20 -0700 To: MOF UML Infrastructure FTF , UML Superstructure FTF From: Joaquin Miller Subject: RE: ,cl, Issue 5979--Proposed closure I think this pure function talk is clumsy, but I understand what the writer was trying to say. However, as this is not in the semantics, it does not really exist (I think the description was just trying to explain the concept). The attachment adds a third alternative text, under the heading, Rewrite: Avoiding pure functions question. Defining a data type by "type whose instances are not objects" won't work, as we have not defined what an object is. I think you need to say something positive about what a data type is... I'll work on this. Cordially, Joaquin Issue 5979 Section 7.12.1--Rev 2.doc Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Date: Tue, 10 Aug 2004 06:20:25 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Proposed closure (defer) for shared issue 5979 Thread-Index: AcR8MVyU9T4A3NNXQNumnDAYMxHACgBMTJ9w From: "Pete Rivett" To: "Thomas Weigert" , "Karl Frank" , "Joaquin Miller" , , X-Virus-Scanned: by amavisd-new at sentraliant.com I think both Don's and Thomas' points have merit. One thing that Don says is that a data type instance must be 'identifiable' in the English sense of the word: you must be able to refer to it (though a difference between the 2 positions is whether there is one Integer 2 (Don) or multiple (Thomas)). And you must be able to refer to the value and compare for 'eq'. While Thomas is right in how identity has traditionally been used in OO circles, even there the full phrase is usually 'has identity independent of its values' - and I do feel that the way it's phrased in the spec is too cryptic: we need to bear in mind that not everyone coming to UML will be well-versed in this OO tradition. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, August 07, 2004 4:31 AM To: Karl Frank; Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Of course Don is wrong. What the spec is saying is that you cannot differentiate between two instances of a data type. E.g., if you have an integer "2" and another integer "2", they are in no way differentiable. In that way, it is said that they have no identity, in that each instance of "2" is exactly like any other. This is different between instances of classes. Even if they have exactly the same values in all their slots, you can tell them apart. For example, in Lisp or Smalltalk there are two comparison operators, "eq" and "equal" (actually, in Lisp there is also "eql", but never mind). Two different objects would never be "eq" even if they are "equal", while two integers that are "equal" are also "eq". In computer science, we usually refer to this difference as that of "identity". So for one, Don does not seem to be familiar with standard computer science terminology. Other things that Don said are incorrect also, e.g., "And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value." But that is precisely the difference between Datatype and Class. You cannot differentiate two occurrences of the same value. Now, of course, it could be the case that we don't want that to be the definition of Datatype, and mean some totally different concept, but then somebody better come along and tell us what that is. However, there are other problems with Datatype. The description section is inconsistent with the actual definition and the semantics. The semantics does not state the constraints implied by the Description section; actually, the definition says that any such constraints are semantic variation points. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, August 06, 2004 11:50 AM To: Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I believe this issue can and should be resolved in this FTF and that Don's views are correct. - Karl -------------------------------------------------------------------------------- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Friday, 06 August, 2004 11:06 AM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 I'm drafting a message on this, but don't have time right now to complete it. I feel we can resolve this now. Does anyone feel that Don is wrong? Or that we don't need to be clear on this? If we do vote to defer, do we want to add a Discussion: Summary of how the issue was proposed to be resolved and/or why it wasn't? I think that this one is safe to put on Ballot 22. OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Date: Tue, 10 Aug 2004 09:52:38 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Proposed closure (defer) for shared issue 5979 Thread-Index: AcR8MVyU9T4A3NNXQNumnDAYMxHACgBMTJ9wAGXIsQA= From: "Karl Frank" To: "Pete Rivett" , "Thomas Weigert" , "Joaquin Miller" , , X-OriginalArrivalTime: 10 Aug 2004 16:52:39.0889 (UTC) FILETIME=[725DCC10:01C47EFA] The reason one does not and cannot differeentiate "two" instances of the integer 2 is precisely because it is one and the same integer, being represented. That is Don's point. Thomas, are you puzzled by Frege's use of identity in "Sinn u. Bedeutung"? Identity is well understood by those outside the OO circle. No mathematician is puzzled by whether different formula involving the integer 2 are talking about a different number or the same number, given that the context makes it clear that the notation is our usual "arabic" and the base is 10, etc. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, August 10, 2004 6:20 AM To: Thomas Weigert; Karl Frank; Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I think both Don's and Thomas' points have merit. One thing that Don says is that a data type instance must be 'identifiable' in the English sense of the word: you must be able to refer to it (though a difference between the 2 positions is whether there is one Integer 2 (Don) or multiple (Thomas)). And you must be able to refer to the value and compare for 'eq'. While Thomas is right in how identity has traditionally been used in OO circles, even there the full phrase is usually 'has identity independent of its values' - and I do feel that the way it's phrased in the spec is too cryptic: we need to bear in mind that not everyone coming to UML will be well-versed in this OO tradition. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, August 07, 2004 4:31 AM To: Karl Frank; Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Of course Don is wrong. What the spec is saying is that you cannot differentiate between two instances of a data type. E.g., if you have an integer "2" and another integer "2", they are in no way differentiable. In that way, it is said that they have no identity, in that each instance of "2" is exactly like any other. This is different between instances of classes. Even if they have exactly the same values in all their slots, you can tell them apart. For example, in Lisp or Smalltalk there are two comparison operators, "eq" and "equal" (actually, in Lisp there is also "eql", but never mind). Two different objects would never be "eq" even if they are "equal", while two integers that are "equal" are also "eq". In computer science, we usually refer to this difference as that of "identity". So for one, Don does not seem to be familiar with standard computer science terminology. Other things that Don said are incorrect also, e.g., "And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value." But that is precisely the difference between Datatype and Class. You cannot differentiate two occurrences of the same value. Now, of course, it could be the case that we don't want that to be the definition of Datatype, and mean some totally different concept, but then somebody better come along and tell us what that is. However, there are other problems with Datatype. The description section is inconsistent with the actual definition and the semantics. The semantics does not state the constraints implied by the Description section; actually, the definition says that any such constraints are semantic variation points. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, August 06, 2004 11:50 AM To: Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I believe this issue can and should be resolved in this FTF and that Don's views are correct. - Karl -------------------------------------------------------------------------------- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Friday, 06 August, 2004 11:06 AM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 I'm drafting a message on this, but don't have time right now to complete it. I feel we can resolve this now. Does anyone feel that Don is wrong? Or that we don't need to be clear on this? If we do vote to defer, do we want to add a Discussion: Summary of how the issue was proposed to be resolved and/or why it wasn't? I think that this one is safe to put on Ballot 22. OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer To: "Karl Frank" Cc: "Joaquin Miller" , mu2i-ftf@omg.org, "Pete Rivett" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 10 Aug 2004 13:22:56 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/10/2004 13:22:59, Serialize complete at 08/10/2004 13:22:59 > Identity is well understood by those outside the OO circle. No > mathematician is puzzled by whether different formula involving the > integer 2 are talking about a different number or the same number, > given that the context makes it clear that the notation is our usual > "arabic" and the base is 10, etc. The problem is that, while mathematicians may agree on what identity is and while OO folks also agree, the two groups do not agree with each other. My desktop Dictionary of Philosophy, which exceptionally has a two-page article on 'identity', claims that identity is what mathematicians mean when they use the '=' sign, while my desktop dictionary of mathematics refutes that. My desktop book on metaphysics dedicates a whole chapter to 'identity'. Jim R's UML reference guide has the standard OO definition of identity which is unlike any of the others. (Yes, I do keep all of those on my desk). It is not our job to reconcile these different worlds. We are wasting time. Defer or close the thing and be done with it. Bran Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Aug 2004 10:33:27 -0700 To: , From: Joaquin Miller Subject: RE: ,cb, Issue 5979 Events, triggers, etc. proposal Consider for example a simple thing like a signal trigger. This is defined by the following grammar fragment to be written on the transition: event-name-list [ .(. assignment-specification .). ] so it could be e.g. .mysig1, mysig2. This is the only thing a user should have to write to specify the trigger. In particular: We should not force a user to somehow separately specify some mysterious .mysig1, mysig2. signal event and then view the text in the trigger as a reference to this event. In other conversations folks seem to have accepted the doctrine that the requirement of a particular element in the model does not mean that the user must insert that element. Instead, if the user inserts an element, and the specification requires one or more other elements, which are completely determined by the first, the tool can insert them This happens all the time with associations. The user just draws a line. The spec requires additional elements, with the cute name, 'association end.' Given that the user has only drawn a line, the association ends are completely determined (they can be changed later by the user). So the tool inserts them into the model (but not into the drawing). No reason this can't be the same with a state machine. If the user feels that trigger specifications are text and has not been admitted to the mystery of the so-called "event," there is no reason she should be troubled with such deep matters. Cordially, Joaquin Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Aug 2004 11:51:13 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,cb, Issue 5979 Events, triggers, etc. proposal Cc: At 10:44 AM 8/10/2004, Joaquin Miller wrote: What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. Would this mean that the same event can not be used with multiple transactions nor with multiple triggers, because it is contained in the trigger, and so is contained in the transaction? Cordially, Joaquin Sorry, all: transitions, not transactions. To: "Karl Frank" Cc: "Joaquin Miller" , mu2i-ftf@omg.org, "Pete Rivett" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Tue, 10 Aug 2004 14:59:57 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/10/2004 13:00:00, Serialize complete at 08/10/2004 13:00:00 Karl, Actually the value object/data type/referentially transparant object can be thought of a little differently than you suggest. The point isn't whether there multiple instances of the integer 2, but that you can't distinguish if there are multiples instances or not, and there's no reason to ever want to. An implementation may use multiple instances if it wants, but a application never needs to know. "Karl Frank" 08/10/2004 12:52 PM To "Pete Rivett" , "Thomas Weigert" , "Joaquin Miller" , , cc Subject RE: ,cl, Proposed closure (defer) for shared issue 5979 The reason one does not and cannot differeentiate "two" instances of the integer 2 is precisely because it is one and the same integer, being represented. That is Don's point. Thomas, are you puzzled by Frege's use of identity in "Sinn u. Bedeutung"? Identity is well understood by those outside the OO circle. No mathematician is puzzled by whether different formula involving the integer 2 are talking about a different number or the same number, given that the context makes it clear that the notation is our usual "arabic" and the base is 10, etc. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, August 10, 2004 6:20 AM To: Thomas Weigert; Karl Frank; Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I think both Don's and Thomas' points have merit. One thing that Don says is that a data type instance must be 'identifiable' in the English sense of the word: you must be able to refer to it (though a difference between the 2 positions is whether there is one Integer 2 (Don) or multiple (Thomas)). And you must be able to refer to the value and compare for 'eq'. While Thomas is right in how identity has traditionally been used in OO circles, even there the full phrase is usually 'has identity independent of its values' - and I do feel that the way it's phrased in the spec is too cryptic: we need to bear in mind that not everyone coming to UML will be well-versed in this OO tradition. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, August 07, 2004 4:31 AM To: Karl Frank; Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Of course Don is wrong. What the spec is saying is that you cannot differentiate between two instances of a data type. E.g., if you have an integer "2" and another integer "2", they are in no way differentiable. In that way, it is said that they have no identity, in that each instance of "2" is exactly like any other. This is different between instances of classes. Even if they have exactly the same values in all their slots, you can tell them apart. For example, in Lisp or Smalltalk there are two comparison operators, "eq" and "equal" (actually, in Lisp there is also "eql", but never mind). Two different objects would never be "eq" even if they are "equal", while two integers that are "equal" are also "eq". In computer science, we usually refer to this difference as that of "identity". So for one, Don does not seem to be familiar with standard computer science terminology. Other things that Don said are incorrect also, e.g., "And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value." But that is precisely the difference between Datatype and Class. You cannot differentiate two occurrences of the same value. Now, of course, it could be the case that we don't want that to be the definition of Datatype, and mean some totally different concept, but then somebody better come along and tell us what that is. However, there are other problems with Datatype. The description section is inconsistent with the actual definition and the semantics. The semantics does not state the constraints implied by the Description section; actually, the definition says that any such constraints are semantic variation points. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, August 06, 2004 11:50 AM To: Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I believe this issue can and should be resolved in this FTF and that Don's views are correct. - Karl -------------------------------------------------------------------------------- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Friday, 06 August, 2004 11:06 AM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 I'm drafting a message on this, but don't have time right now to complete it. I feel we can resolve this now. Does anyone feel that Don is wrong? Or that we don't need to be clear on this? If we do vote to defer, do we want to add a Discussion: Summary of how the issue was proposed to be resolved and/or why it wasn't? I think that this one is safe to put on Ballot 22. OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Date: Tue, 10 Aug 2004 13:37:23 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Proposed closure (defer) for shared issue 5979 Thread-Index: AcR/DEHdkXqeEmvOQrehUJjU3r27fQAC9jaA From: "Karl Frank" To: "Jim Amsden" Cc: "Joaquin Miller" , , "Pete Rivett" , "Thomas Weigert" , X-OriginalArrivalTime: 10 Aug 2004 20:37:25.0257 (UTC) FILETIME=[D845A790:01C47F19] Jim, Sorry that I did not explain myself better. The point is, is the UML spec is right in saying "A Data Type is a type whose values have no identity" ? If individual integers didn't have identity, you couldn't tell 3 from 4, nor determine whether x = y or x != y. And these individual integers are the values for the Integer data type. Therefore, integers are a type whose values can be identified, and since Integer is a Data Type, it is false that a data type is a type whose values have no identity. I am not arguing that the values of the int datatype in C++ have an OID, everyone knows they do not I certainly agree with you that the point isn't whether there are multiple instances of the integer 2. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, August 10, 2004 3:00 PM To: Karl Frank Cc: Joaquin Miller; mu2i-ftf@omg.org; Pete Rivett; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Karl, Actually the value object/data type/referentially transparant object can be thought of a little differently than you suggest. The point isn't whether there multiple instances of the integer 2, but that you can't distinguish if there are multiples instances or not, and there's no reason to ever want to. An implementation may use multiple instances if it wants, but a application never needs to know. "Karl Frank" 08/10/2004 12:52 PM To "Pete Rivett" , "Thomas Weigert" , "Joaquin Miller" , , cc Subject RE: ,cl, Proposed closure (defer) for shared issue 5979 The reason one does not and cannot differeentiate "two" instances of the integer 2 is precisely because it is one and the same integer, being represented. That is Don's point. Thomas, are you puzzled by Frege's use of identity in "Sinn u. Bedeutung"? Identity is well understood by those outside the OO circle. No mathematician is puzzled by whether different formula involving the integer 2 are talking about a different number or the same number, given that the context makes it clear that the notation is our usual "arabic" and the base is 10, etc. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, August 10, 2004 6:20 AM To: Thomas Weigert; Karl Frank; Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I think both Don's and Thomas' points have merit. One thing that Don says is that a data type instance must be 'identifiable' in the English sense of the word: you must be able to refer to it (though a difference between the 2 positions is whether there is one Integer 2 (Don) or multiple (Thomas)). And you must be able to refer to the value and compare for 'eq'. While Thomas is right in how identity has traditionally been used in OO circles, even there the full phrase is usually 'has identity independent of its values' - and I do feel that the way it's phrased in the spec is too cryptic: we need to bear in mind that not everyone coming to UML will be well-versed in this OO tradition. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, August 07, 2004 4:31 AM To: Karl Frank; Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Of course Don is wrong. What the spec is saying is that you cannot differentiate between two instances of a data type. E.g., if you have an integer "2" and another integer "2", they are in no way differentiable. In that way, it is said that they have no identity, in that each instance of "2" is exactly like any other. This is different between instances of classes. Even if they have exactly the same values in all their slots, you can tell them apart. For example, in Lisp or Smalltalk there are two comparison operators, "eq" and "equal" (actually, in Lisp there is also "eql", but never mind). Two different objects would never be "eq" even if they are "equal", while two integers that are "equal" are also "eq". In computer science, we usually refer to this difference as that of "identity". So for one, Don does not seem to be familiar with standard computer science terminology. Other things that Don said are incorrect also, e.g., "And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value." But that is precisely the difference between Datatype and Class. You cannot differentiate two occurrences of the same value. Now, of course, it could be the case that we don't want that to be the definition of Datatype, and mean some totally different concept, but then somebody better come along and tell us what that is. However, there are other problems with Datatype. The description section is inconsistent with the actual definition and the semantics. The semantics does not state the constraints implied by the Description section; actually, the definition says that any such constraints are semantic variation points. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, August 06, 2004 11:50 AM To: Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I believe this issue can and should be resolved in this FTF and that Don's views are correct. - Karl -------------------------------------------------------------------------------- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Friday, 06 August, 2004 11:06 AM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 I'm drafting a message on this, but don't have time right now to complete it. I feel we can resolve this now. Does anyone feel that Don is wrong? Or that we don't need to be clear on this? If we do vote to defer, do we want to add a Discussion: Summary of how the issue was proposed to be resolved and/or why it wasn't? I think that this one is safe to put on Ballot 22. OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Aug 2004 15:58:38 -0700 To: , From: Joaquin Miller Subject: RE: ,cb, Issue 5979 Events, triggers, etc. proposal Events are something that occurs. Occurrences are basically points in time when there was some noteworthy change in state. They have no behavior, and need no ports. Triggers a link between an event and something that cares when a particular kind of event occurs. Here, a port would be useful because it provides an interaction point. Events do not have interaction points, but the notification of event occurrence needs one. Along those same lines: A UML 2 event is the representation in a model of a type of occurrence (=something that happens). Likewise, a UML 2 transition is a representation of a type of occurrence (the change of state, or the execution that changes the state, or however you want to explain that). A UML 2 trigger is something of a different genus. It does not represent something of the same kind at all. Instead it is an element of a specification. It says: when this happens, then that is to happen. I'm not arguing for or against retaining or killing trigger. But i feel it will be better if we are explicit about what we are doing. As i am sure we all agree, if we do kill trigger we have to place its function in some other element. The only candidates in sight are the transition and a role, i.e. association end, of the association from transition to event. (If that association is quote "navigable" unquote, then i guess there is no difference between the alternatives. They are identical.) Cordially, Joaquin From: "Thomas Weigert" To: "Karl Frank" , "Jim Amsden" Cc: "Joaquin Miller" , , "Pete Rivett" , Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Date: Tue, 10 Aug 2004 23:00:56 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Karl, you are misquoting what it means to have identity. By saying Integers do not have identity, we are saying that you cannot tell this "3" from that "3". (But of course, you know that). This is the same as saying that Integers are only differentiated by their value. The same is true for all other datatypes. Of course you could come up with a convention that says that integers are identified by their value. But what would the point of that be? All we are really discussing here is what comparison function between things we call "identity" and which we call "equality". Let's stick with conventional usage of these terms. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, August 10, 2004 3:37 PM To: Jim Amsden Cc: Joaquin Miller; mu2i-ftf@omg.org; Pete Rivett; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Jim, Sorry that I did not explain myself better. The point is, is the UML spec is right in saying "A Data Type is a type whose values have no identity" ? If individual integers didn't have identity, you couldn't tell 3 from 4, nor determine whether x = y or x != y. And these individual integers are the values for the Integer data type. Therefore, integers are a type whose values can be identified, and since Integer is a Data Type, it is false that a data type is a type whose values have no identity. I am not arguing that the values of the int datatype in C++ have an OID, everyone knows they do not I certainly agree with you that the point isn't whether there are multiple instances of the integer 2. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, August 10, 2004 3:00 PM To: Karl Frank Cc: Joaquin Miller; mu2i-ftf@omg.org; Pete Rivett; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Karl, Actually the value object/data type/referentially transparant object can be thought of a little differently than you suggest. The point isn't whether there multiple instances of the integer 2, but that you can't distinguish if there are multiples instances or not, and there's no reason to ever want to. An implementation may use multiple instances if it wants, but a application never needs to know. "Karl Frank" 08/10/2004 12:52 PM To "Pete Rivett" , "Thomas Weigert" , "Joaquin Miller" , , cc Subject RE: ,cl, Proposed closure (defer) for shared issue 5979 The reason one does not and cannot differeentiate "two" instances of the integer 2 is precisely because it is one and the same integer, being represented. That is Don's point. Thomas, are you puzzled by Frege's use of identity in "Sinn u. Bedeutung"? Identity is well understood by those outside the OO circle. No mathematician is puzzled by whether different formula involving the integer 2 are talking about a different number or the same number, given that the context makes it clear that the notation is our usual "arabic" and the base is 10, etc. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, August 10, 2004 6:20 AM To: Thomas Weigert; Karl Frank; Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I think both Don's and Thomas' points have merit. One thing that Don says is that a data type instance must be 'identifiable' in the English sense of the word: you must be able to refer to it (though a difference between the 2 positions is whether there is one Integer 2 (Don) or multiple (Thomas)). And you must be able to refer to the value and compare for 'eq'. While Thomas is right in how identity has traditionally been used in OO circles, even there the full phrase is usually 'has identity independent of its values' - and I do feel that the way it's phrased in the spec is too cryptic: we need to bear in mind that not everyone coming to UML will be well-versed in this OO tradition. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, August 07, 2004 4:31 AM To: Karl Frank; Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Of course Don is wrong. What the spec is saying is that you cannot differentiate between two instances of a data type. E.g., if you have an integer "2" and another integer "2", they are in no way differentiable. In that way, it is said that they have no identity, in that each instance of "2" is exactly like any other. This is different between instances of classes. Even if they have exactly the same values in all their slots, you can tell them apart. For example, in Lisp or Smalltalk there are two comparison operators, "eq" and "equal" (actually, in Lisp there is also "eql", but never mind). Two different objects would never be "eq" even if they are "equal", while two integers that are "equal" are also "eq". In computer science, we usually refer to this difference as that of "identity". So for one, Don does not seem to be familiar with standard computer science terminology. Other things that Don said are incorrect also, e.g., "And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value." But that is precisely the difference between Datatype and Class. You cannot differentiate two occurrences of the same value. Now, of course, it could be the case that we don't want that to be the definition of Datatype, and mean some totally different concept, but then somebody better come along and tell us what that is. However, there are other problems with Datatype. The description section is inconsistent with the actual definition and the semantics. The semantics does not state the constraints implied by the Description section; actually, the definition says that any such constraints are semantic variation points. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, August 06, 2004 11:50 AM To: Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I believe this issue can and should be resolved in this FTF and that Don's views are correct. - Karl -------------------------------------------------------------------------------- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Friday, 06 August, 2004 11:06 AM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 I'm drafting a message on this, but don't have time right now to complete it. I feel we can resolve this now. Does anyone feel that Don is wrong? Or that we don't need to be clear on this? If we do vote to defer, do we want to add a Discussion: Summary of how the issue was proposed to be resolved and/or why it wasn't? I think that this one is safe to put on Ballot 22. OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer From: "Thomas Weigert" To: "Branislav Selic" , "Karl Frank" Cc: "Joaquin Miller" , , "Pete Rivett" , Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Date: Tue, 10 Aug 2004 23:05:32 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Agreed. There is no point in solving this, as there is no right or wrong. We should stick with the traditional computer science view (which by the way, goes beyond OO). Karl, if you want to argue philosophy, I would focus on Kripke, rather than Frege. There has been a lot of advances since the fin de sciecle. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 10, 2004 12:23 PM To: Karl Frank Cc: Joaquin Miller; mu2i-ftf@omg.org; Pete Rivett; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 > Identity is well understood by those outside the OO circle. No > mathematician is puzzled by whether different formula involving the > integer 2 are talking about a different number or the same number, > given that the context makes it clear that the notation is our usual > "arabic" and the base is 10, etc. The problem is that, while mathematicians may agree on what identity is and while OO folks also agree, the two groups do not agree with each other. My desktop Dictionary of Philosophy, which exceptionally has a two-page article on 'identity', claims that identity is what mathematicians mean when they use the '=' sign, while my desktop dictionary of mathematics refutes that. My desktop book on metaphysics dedicates a whole chapter to 'identity'. Jim R's UML reference guide has the standard OO definition of identity which is unlike any of the others. (Yes, I do keep all of those on my desk). It is not our job to reconcile these different worlds. We are wasting time. Defer or close the thing and be done with it. Bran Subject: RE: ,cb, Issue 5979 Events, triggers, etc. proposal Date: Wed, 11 Aug 2004 16:05:58 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cb, Issue 5979 Events, triggers, etc. proposal Thread-Index: AcR/Ly3wItssPkmrTAS/NtrjYFpkAQAfM71A From: "Anders Ek" To: "Joaquin Miller" , , Just a question: The event should contain relevant information about what has happened. Why is not the information about what port a signal was consumed on also relevant information? /Anders -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: den 11 augusti 2004 00:59 To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: ,cb, Issue 5979 Events, triggers, etc. proposal Events are something that occurs. Occurrences are basically points in time when there was some noteworthy change in state. They have no behavior, and need no ports. Triggers a link between an event and something that cares when a particular kind of event occurs. Here, a port would be useful because it provides an interaction point. Events do not have interaction points, but the notification of event occurrence needs one. Along those same lines: A UML 2 event is the representation in a model of a type of occurrence (=something that happens). Likewise, a UML 2 transition is a representation of a type of occurrence (the change of state, or the execution that changes the state, or however you want to explain that). A UML 2 trigger is something of a different genus. It does not represent something of the same kind at all. Instead it is an element of a specification. It says: when this happens, then that is to happen. I'm not arguing for or against retaining or killing trigger. But i feel it will be better if we are explicit about what we are doing. As i am sure we all agree, if we do kill trigger we have to place its function in some other element. The only candidates in sight are the transition and a role, i.e. association end, of the association from transition to event. (If that association is quote "navigable" unquote, then i guess there is no difference between the alternatives. They are identical.) Cordially, Joaquin Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Date: Wed, 11 Aug 2004 18:48:26 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Proposed closure (defer) for shared issue 5979 Thread-Index: AcSADHzIuRD3VDA3Qh+gtITKdHZCxwAAEOVA From: "Karl Frank" To: "Thomas Weigert" , "Jim Amsden" Cc: "Joaquin Miller" , , "Pete Rivett" , X-OriginalArrivalTime: 12 Aug 2004 01:48:28.0167 (UTC) FILETIME=[76A57970:01C4800E] Thomas, Thanks for sticking with this topic, even if the UML spec does not benefit, I find that the reason Don B. and I differ with you and Bran (and others) is becoming clear, imho. Our differences come down to this, one camp is using 'identity' in the way peculiar to OO software, and the other is using it in the way of the logic of identity. According to the logic of identity, everything in every domain conforms to the axiom, (for all x) isIdenticalWith(x, x) And according to this way of thinking, it follows that everything has identity. Because it is the subject of a true identiy statement, namely that it is identical with itself. It doesn't matter whether the domain is integer values, or object references. |- (x)(x=x) using '=' as isIdenticalWith in infix notational mode. According to the OO programming approach (which is a niche only a few decades old, in comparison with centuries of agreement about the logic of identity), an object stored in a computer is what is at some address (the physical address can be moved around transparently by the operating system for memory management convenience). So the exact same object has to be what is at that address. A case of (x)(x=x) Numbers of course are not arrangements of charges on capcitors, but are mathematical entities, equally represented by various bit arrays and pencil marks on paper, so in judging the identity of numbers, it is irrelevant to attend to the memory address at a bit array, typed as an int, may be stored. So it is the identity of the value represented that is in question, not the address at which the bit array may be found. So, the OO thinkers say AHA!, integers have no identity ! A nonsequitor. - karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, August 11, 2004 12:01 AM To: Karl Frank; Jim Amsden Cc: Joaquin Miller; mu2i-ftf@omg.org; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Karl, you are misquoting what it means to have identity. By saying Integers do not have identity, we are saying that you cannot tell this "3" from that "3". (But of course, you know that). This is the same as saying that Integers are only differentiated by their value. The same is true for all other datatypes. Of course you could come up with a convention that says that integers are identified by their value. But what would the point of that be? All we are really discussing here is what comparison function between things we call "identity" and which we call "equality". Let's stick with conventional usage of these terms. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, August 10, 2004 3:37 PM To: Jim Amsden Cc: Joaquin Miller; mu2i-ftf@omg.org; Pete Rivett; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Jim, Sorry that I did not explain myself better. The point is, is the UML spec is right in saying "A Data Type is a type whose values have no identity" ? If individual integers didn't have identity, you couldn't tell 3 from 4, nor determine whether x = y or x != y. And these individual integers are the values for the Integer data type. Therefore, integers are a type whose values can be identified, and since Integer is a Data Type, it is false that a data type is a type whose values have no identity. I am not arguing that the values of the int datatype in C++ have an OID, everyone knows they do not I certainly agree with you that the point isn't whether there are multiple instances of the integer 2. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, August 10, 2004 3:00 PM To: Karl Frank Cc: Joaquin Miller; mu2i-ftf@omg.org; Pete Rivett; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Karl, Actually the value object/data type/referentially transparant object can be thought of a little differently than you suggest. The point isn't whether there multiple instances of the integer 2, but that you can't distinguish if there are multiples instances or not, and there's no reason to ever want to. An implementation may use multiple instances if it wants, but a application never needs to know. "Karl Frank" 08/10/2004 12:52 PM To "Pete Rivett" , "Thomas Weigert" , "Joaquin Miller" , , cc Subject RE: ,cl, Proposed closure (defer) for shared issue 5979 The reason one does not and cannot differeentiate "two" instances of the integer 2 is precisely because it is one and the same integer, being represented. That is Don's point. Thomas, are you puzzled by Frege's use of identity in "Sinn u. Bedeutung"? Identity is well understood by those outside the OO circle. No mathematician is puzzled by whether different formula involving the integer 2 are talking about a different number or the same number, given that the context makes it clear that the notation is our usual "arabic" and the base is 10, etc. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, August 10, 2004 6:20 AM To: Thomas Weigert; Karl Frank; Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I think both Don's and Thomas' points have merit. One thing that Don says is that a data type instance must be 'identifiable' in the English sense of the word: you must be able to refer to it (though a difference between the 2 positions is whether there is one Integer 2 (Don) or multiple (Thomas)). And you must be able to refer to the value and compare for 'eq'. While Thomas is right in how identity has traditionally been used in OO circles, even there the full phrase is usually 'has identity independent of its values' - and I do feel that the way it's phrased in the spec is too cryptic: we need to bear in mind that not everyone coming to UML will be well-versed in this OO tradition. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, August 07, 2004 4:31 AM To: Karl Frank; Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 Of course Don is wrong. What the spec is saying is that you cannot differentiate between two instances of a data type. E.g., if you have an integer "2" and another integer "2", they are in no way differentiable. In that way, it is said that they have no identity, in that each instance of "2" is exactly like any other. This is different between instances of classes. Even if they have exactly the same values in all their slots, you can tell them apart. For example, in Lisp or Smalltalk there are two comparison operators, "eq" and "equal" (actually, in Lisp there is also "eql", but never mind). Two different objects would never be "eq" even if they are "equal", while two integers that are "equal" are also "eq". In computer science, we usually refer to this difference as that of "identity". So for one, Don does not seem to be familiar with standard computer science terminology. Other things that Don said are incorrect also, e.g., "And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value." But that is precisely the difference between Datatype and Class. You cannot differentiate two occurrences of the same value. Now, of course, it could be the case that we don't want that to be the definition of Datatype, and mean some totally different concept, but then somebody better come along and tell us what that is. However, there are other problems with Datatype. The description section is inconsistent with the actual definition and the semantics. The semantics does not state the constraints implied by the Description section; actually, the definition says that any such constraints are semantic variation points. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, August 06, 2004 11:50 AM To: Joaquin Miller; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: ,cl, Proposed closure (defer) for shared issue 5979 I believe this issue can and should be resolved in this FTF and that Don's views are correct. - Karl -------------------------------------------------------------------------------- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Friday, 06 August, 2004 11:06 AM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed closure (defer) for shared issue 5979 I'm drafting a message on this, but don't have time right now to complete it. I feel we can resolve this now. Does anyone feel that Don is wrong? Or that we don't need to be clear on this? If we do vote to defer, do we want to add a Discussion: Summary of how the issue was proposed to be resolved and/or why it wasn't? I think that this one is safe to put on Ballot 22. OMG Issue No: 5979 Title: The description of DataType is plainly wrong in the specification Source: Unisys (Mr. Don Baisley, donald.baisley@unisys.com ) Summary: The description of DataType is plainly wrong in the specification. A data type is a classification of data values. The identity of a data value is based on the value itself. And the identity definitely exists. Otherwise you would not be able to know when you had two occurrences of the same value. If a value has no identity, it would not be possible to distinguish different values of the same data type. Someone has confused the concept of having identity with the concept of having a memory address. Note also that an instance specification is capable, according to the specification, of identifying a data value, so it is a contradiction to say a data value has no identity. Perhaps the specification is using the word "identity" in a way that is completely different from anything in my dictionary. The key point to make is that a data value is not to be confused with a data variable or a slot in an object that can hold a data value. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Defer From: "Thomas Weigert" To: "Joaquin Miller" Cc: "UML Superstructure FTF" Subject: RE: ,cl, Issue 5979 Section 7.12.1--Rev 4 Date: Wed, 18 Aug 2004 17:19:52 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Joaquin, thanks for the text. The phrase quoted below is a good one, albeit it says exactly what the current text says, just in different words. However, the rest is still not what I hoped for. I am attaching a proposed rewrite of your text. I have moved text between sections to be more appropriate (for example, and example explaining the overall concept should be in description, not in semantics) and removed the declaration of intention (as this is not clear at all). Th. > -----Original Message----- > From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] > Sent: Wednesday, August 18, 2004 4:12 PM > To: Thomas Weigert > Subject: ,cl, Issue 5979 Section 7.12.1--Rev 4 > > > Thomas, sorry for the delay. Karl calls to our attention that there is a > text explaining data types already in the adopted Infrastructure in the > Basic package. He suggests we reuse this. > > A data type is a type whose instances are identified only > by their value. > > So i have rewritten using that. I have left in the paragraph about > equivalence. As you suggested, I have added text to cover structured > values; if that can be sharpened up, please do. > > I have checked again against each of your five points and tried to cover > them all (except for the mention of Class in number 4, which i would like > to keep separate). > > Let me know if this is OK, and i will send it to Bran. > > Cordially, Joaquin > > > > PGP Fingerprint: > CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 > Issue 5979 Section 7.12.1--Rev 4.doc Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 18 Aug 2004 15:54:50 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,cl, Issue 5979 Section 7.12.1--Rev 4 Excellent, Thomas. Much improved. Thanks. I feel this wraps it up. I will bring up the same change in the MOF+Infra call tomorrow. Cordially, Joaquin At 03:19 PM 8/18/2004, Thomas Weigert wrote: Joaquin, thanks for the text. The phrase quoted below is a good one, albeit it says exactly what the current text says, just in different words. However, the rest is still not what I hoped for. I am attaching a proposed rewrite of your text. I have moved text between sections to be more appropriate (for example, and example explaining the overall concept should be in description, not in semantics) and removed the declaration of intention (as this is not clear at all). Th. > -----Original Message----- > From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] > Sent: Wednesday, August 18, 2004 4:12 PM > To: Thomas Weigert > Subject: ,cl, Issue 5979 Section 7.12.1--Rev 4 > > > Thomas, sorry for the delay. Karl calls to our attention that there is a > text explaining data types already in the adopted Infrastructure in the > Basic package. He suggests we reuse this. > > A data type is a type whose instances are identified only > by their value. > > So i have rewritten using that. I have left in the paragraph about > equivalence. As you suggested, I have added text to cover structured > values; if that can be sharpened up, please do. > > I have checked again against each of your five points and tried to cover > them all (except for the mention of Class in number 4, which i would like > to keep separate). > > Let me know if this is OK, and i will send it to Bran. > > Cordially, Joaquin > > > > PGP Fingerprint: > CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 > To: "Thomas Weigert" Cc: "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: ,cl, Issue 5979 Section 7.12.1--Rev 4 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 20 Aug 2004 10:31:35 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/20/2004 10:31:37, Serialize complete at 08/20/2004 10:31:37 Gentlemen, is there any reason why you folks left out the long list of "style guidelines" for data types? (you kept only one) My plan is to re-instate those guidelines and then create a clone of this for Infrastructure. If you have any objections, tell me ASAP. Thanks, Bran "Thomas Weigert" 08/18/2004 06:19 PM To "Joaquin Miller" cc "UML Superstructure FTF" Subject RE: ,cl, Issue 5979 Section 7.12.1--Rev 4 Joaquin, thanks for the text. The phrase quoted below is a good one, albeit it says exactly what the current text says, just in different words. However, the rest is still not what I hoped for. I am attaching a proposed rewrite of your text. I have moved text between sections to be more appropriate (for example, and example explaining the overall concept should be in description, not in semantics) and removed the declaration of intention (as this is not clear at all). Th. > -----Original Message----- > From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] > Sent: Wednesday, August 18, 2004 4:12 PM > To: Thomas Weigert > Subject: ,cl, Issue 5979 Section 7.12.1--Rev 4 > > > Thomas, sorry for the delay. Karl calls to our attention that there is a > text explaining data types already in the adopted Infrastructure in the > Basic package. He suggests we reuse this. > > A data type is a type whose instances are identified only > by their value. > > So i have rewritten using that. I have left in the paragraph about > equivalence. As you suggested, I have added text to cover structured > values; if that can be sharpened up, please do. > > I have checked again against each of your five points and tried to cover > them all (except for the mention of Class in number 4, which i would like > to keep separate). > > Let me know if this is OK, and i will send it to Bran. > > Cordially, Joaquin > > > > PGP Fingerprint: > CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 > [attachment "Issue 5979 Section 7.12.1--Rev 4.doc" deleted by Branislav Selic/Ottawa/IBM] From: "Thomas Weigert" To: "Branislav Selic" Cc: "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: ,cl, Issue 5979 Section 7.12.1--Rev 4 Date: Fri, 20 Aug 2004 09:35:44 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) The guidelines have been removed as they apply to classifier in general. They should have been moved to and merged into "Classifier, Style Guidelines". Apparently that was omitted in the resolution. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 20, 2004 9:32 AM To: Thomas Weigert Cc: Joaquin Miller; UML Superstructure FTF Subject: RE: ,cl, Issue 5979 Section 7.12.1--Rev 4 Gentlemen, is there any reason why you folks left out the long list of "style guidelines" for data types? (you kept only one) My plan is to re-instate those guidelines and then create a clone of this for Infrastructure. If you have any objections, tell me ASAP. Thanks, Bran "Thomas Weigert" 08/18/2004 06:19 PM To "Joaquin Miller" cc "UML Superstructure FTF" Subject RE: ,cl, Issue 5979 Section 7.12.1--Rev 4 Joaquin, thanks for the text. The phrase quoted below is a good one, albeit it says exactly what the current text says, just in different words. However, the rest is still not what I hoped for. I am attaching a proposed rewrite of your text. I have moved text between sections to be more appropriate (for example, and example explaining the overall concept should be in description, not in semantics) and removed the declaration of intention (as this is not clear at all). Th. > -----Original Message----- > From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] > Sent: Wednesday, August 18, 2004 4:12 PM > To: Thomas Weigert > Subject: ,cl, Issue 5979 Section 7.12.1--Rev 4 > > > Thomas, sorry for the delay. Karl calls to our attention that there is a > text explaining data types already in the adopted Infrastructure in the > Basic package. He suggests we reuse this. > > A data type is a type whose instances are identified only > by their value. > > So i have rewritten using that. I have left in the paragraph about > equivalence. As you suggested, I have added text to cover structured > values; if that can be sharpened up, please do. > > I have checked again against each of your five points and tried to cover > them all (except for the mention of Class in number 4, which i would like > to keep separate). > > Let me know if this is OK, and i will send it to Bran. > > Cordially, Joaquin > > > > PGP Fingerprint: > CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 > [attachment "Issue 5979 Section 7.12.1--Rev 4.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 02:22:18 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGUaOOvWEvXmwvTEeA2cPkA+ZL9gAHR9rg Priority: Urgent From: "Pete Rivett" To: "Branislav Selic" , , X-Virus-Scanned: by amavisd-new at sentraliant.com 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran Reply-To: From: "Conrad Bock" To: , Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 13:04:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Comments on ballot 24 below. Conrad - 4932 (Starting state machine) Typo: replace "filter" with "filer". - 5979 (The description of DataType is plainly wrong in the specification) Typo: "considered the be the same". I assume the Figure 41 example will be included in the final document, even though it isn't in the resolution? The removal of presentation options and style guidelines is a separate issue isn't it? - 6171 (Operation) The new text should refer to Generalization::isSubstitutable, rather than say issues of substitutability are out of scope. - 6616 (UML Superstructure FTF : isRoot property disappeared) The resolution says that isRoot can be derived from whether a classifier has supertypes. This is incorrect, because isRoot is a record for modeler intent that no supertypes will be defined for the classifier. It is analogous to isLeaf, which declares there will be no subtypes, so compilers can optimize message passing into function invocation. I don't mind that isRoot was removed, but the issue should not say it is derivable. - 6902 (Identify sections specifying run-time semantics) Thanks for the update on this. Combined with Jim R's much improved description of events in common behavior, this will be OK for process modelers. (Since the separation of inter- and intra-object is not reflected much in actions and behaviors, it still seems a little confusing, but we don't have time for another update). Typo: "TThese". - 6975 (missing illustrations of graphical paths for create and destroy message) The issues asks for examples, not new notation. That seems reasonable, so this one can be deferred. - 7219 (Operations and derived attributes) One of the roles of FTF/RTF's is to answer questions, even if there is no change. If there is not time to answer these, they can be deferred. - 7438 (Section: 12.3.3) The resolution is incorrect (this should have been assigned to Activities). Here is the resolution: "Connectors are purely notational and have no name. The name displayed is the name of the edge. This is stated by the first sentence under Figure 207. However, there may be an issue that edges are not contained by ownedMember, to be restricted by the Activity namespace, but this requires more discussion to resolve." Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 21 Aug 2004 10:24:17 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Ballot 24 draft - 5979 (The description of DataType is plainly wrong in the specification) I assume the Figure 41 example will be included in the final document, even though it isn't in the resolution? That was the intent. Sorry. value.