Issue 8274: UML2/Infra section 11.6.2/ Enumerations should not have attributes (uml2-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: 11.6.2 of Infra and 7.3.16 of Super refer to the possibility of Enumerations having attributes: "A compartment listing the attributes for the enumeration is placed below the name compartment." This concept does not make sense to me: an enumeration inherently represents a single value-set modeled through owned EnumerationLiterals. The only type of attribute that might ever make sense is a derived attribute (e.g. Color.isPrimary). Proposed resolution: Add constraint to above sections on Enumeration to state that only attributes permitted are derived ones. Also that any Operation must have isQuery=true. Resolution: Enumeration literals are immutable, so writeable attributes do not make sense. But read-only attributes do make sense: they don’t need to be derived. The current description of equality of EnumerationLiterals needs improvement. Operations on enumerations are allowed. This also resolves 17933 Revised Text: In 10.2.3, in the semantics for Enumerations, replace: The run-time values corresponding to EnumerationLiterals may be compared for equality by: Values corresponding to EnumerationLiterals are immutable and may be compared for equality. EnumerationLiterals may not change during their existence, so any attributes on an Enumeration shall be read-only. Add the following constraint to Enumeration: immutable ownedAttribute->forAll(isReadOnly) Actions taken: February 14, 2005: received issue February 20, 2015: closed issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== ubject: UML2/Infra section 11.6.2/ Enumerations should not have attributes Date: Mon, 14 Feb 2005 13:12:08 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AcUSvsIAWaZK7TwNT5uYrELPIiCHcQ== From: "Pete Rivett" To: X-Virus-Scanned: by amavisd-new at sentraliant.com 11.6.2 of Infra and 7.3.16 of Super refer to the possibility of Enumerations having attributes: "A compartment listing the attributes for the enumeration is placed below the name compartment." This concept does not make sense to me: an enumeration inherently represents a single value-set modeled through owned EnumerationLiterals. The only type of attribute that might ever make sense is a derived attribute (e.g. Color.isPrimary). Proposed resolution: Add constraint to above sections on Enumeration to state that only attributes permitted are derived ones. Also that any Operation must have isQuery=true. Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, 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 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=N/334RBB c=1 sm=1 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=LtPsvfKgyxgA:10 a=nySX46TQ6fEA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=UMmbHRLnWeUA:10 a=vsNid6RKTpmAqbLMr_cA:9 a=wPNLvfGTeEIA:10 a=eW53zEZrsyElcQ0NK1QpqA==:117 Date: Thu, 11 Apr 2013 17:13:31 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 To: "uml25-ftf@omg.org" Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink From: Steve Cook To: Ed Willink , "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/mYUDCX6Lw3EiryquvTAL6/pjRNFCg Date: Thu, 11 Apr 2013 16:28:25 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(13464002)(199002)(5403001)(189002)(76482001)(47976001)(81542001)(47446002)(56816002)(20776003)(63696002)(51856001)(44976002)(23726001)(4396001)(74502001)(46102001)(54316002)(47776003)(55846006)(50466001)(65816001)(47736001)(5343655001)(69226001)(31966008)(53806001)(50986001)(80022001)(74662001)(49866001)(56776001)(54356001)(77982001)(16406001)(33656001)(46406002)(79102001)(59766001)(81342001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB004;H:TK5EX14MLTC103.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0813C68E65 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r3BGTYGc020802 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink X-Virus-Scanned: OK From: Ed Seidewitz To: Steve Cook CC: Ed Willink , "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/DnWyU9Fk3cEGmdKYiPD1fxZjRiWCA//+tUNA= Date: Thu, 11 Apr 2013 16:44:00 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.48.209.197] X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r3BGi6tl022865 X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== Steve -- Except that is kind of pointless, isn't it? The instance of ANY metaclass is "equal to itself and not equal to anything other than itself" (since instances of metaclasses are objects with identity). The sentence being replaced talks about the "run-time value representing an EnumerationLiteral", and this appears under "Semantics". So, clearly, what is under discussion is the M0 meaning of an EnumerationLiteral as representing a data value of its Enumeration, not the M1 instance of the metaclass EnumerationLiteral. While I agree that "object memory address" does not really have a meaning for UML, I think that "EnumerationLiteral value" DOES having a meaning, and is exactly what is being referenced here when the text talks about "equality" and "immutability". This is in the same sense in which objects are value as instances of classes and data values are values as instances of data types -- it is just that, in the case of an Enumeration, we happen to have EnumerationLiteral model elements that directly represent the explicitly enumerated instances of the Enumeration. (This is explicit in the fUML Execution Model, by the way, in which there may be multiple EnumerationLiteralValues that point to the same M1 EnumerationLiteral, but any two EnumerationLiteralValues for the same EnumerationLiteral are considered to be equal.) -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, April 11, 2013 12:28 PM To: Ed Willink; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=AshsLZBP c=1 sm=0 a=pOnlXI+OzIR+VovaE1yrCQ==:17 a=_8h-72LBZA0A:10 a=unG0xv2_G3sA:10 a=xAbV8cneAAAA:8 a=5T5ACBRsdd8A:10 a=5DqnjfGMAAAA:8 a=yMhMjlubAAAA:8 a=KHpXyVWLAAAA:8 a=YYzpnO7rAAAA:8 a=fD0B4Odes5yH5yyqA1oA:9 a=CjuIK1q_8ugA:10 a=IbaMUZ3Y20wA:10 a=Yei7sYp_unwA:10 a=4X2vG_HZxQ0A:10 a=j_rQ7akP1FUA:10 a=ngL6kCF7wasA:10 a=-AOE9ft50oIA:10 a=WP4_USCxRkkA:10 a=a4i3Vb1DcrUA:10 a=tLGXAVmgyYcr0H-d:21 a=A3cT23Z55ccRvsnm:21 a=v0dtTIfLPzsV2zAMnQwA:9 a=_W_S_7VecoQA:10 a=HZaGLp-M0XcvSP8S:21 a=pOPJKy177Nuv9PslSwsA:9 a=pOnlXI+OzIR+VovaE1yrCQ==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=koethe@88solutions.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=koethe@88solutions.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=koethe; auth=pass (PLAIN) Subject: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes From: "Manfred R. Koethe" Date: Thu, 11 Apr 2013 10:16:20 -0700 Cc: Steve Cook , Ed Willink , Ed Seidewitz To: "uml25-ftf@omg.org" X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Are we trying to interpret too much into that? To my understanding, an enumeration is a type with a finite set of discrete and explicitly defined values. That are the EnumerationLiterals, ordinary data values, just created differently than for example a "1" as an Integer data value. Do I miss something? Manfred On Apr 11, 2013, at 9:44 , Ed Seidewitz wrote: Steve -- Except that is kind of pointless, isn't it? The instance of ANY metaclass is "equal to itself and not equal to anything other than itself" (since instances of metaclasses are objects with identity). The sentence being replaced talks about the "run-time value representing an EnumerationLiteral", and this appears under "Semantics". So, clearly, what is under discussion is the M0 meaning of an EnumerationLiteral as representing a data value of its Enumeration, not the M1 instance of the metaclass EnumerationLiteral. While I agree that "object memory address" does not really have a meaning for UML, I think that "EnumerationLiteral value" DOES having a meaning, and is exactly what is being referenced here when the text talks about "equality" and "immutability". This is in the same sense in which objects are value as instances of classes and data values are values as instances of data types -- it is just that, in the case of an Enumeration, we happen to have EnumerationLiteral model elements that directly represent the explicitly enumerated instances of the Enumeration. (This is explicit in the fUML Execution Model, by the way, in which there may be multiple EnumerationLiteralValues that point to the same M1 EnumerationLiteral, but any two EnumerationLiteralValues for the same EnumerationLiteral are considered to be equal.) -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, April 11, 2013 12:28 PM To: Ed Willink; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- signature11.asc signature11.asc From: "Wendland, Marc-Florian" To: "Manfred R. Koethe" , "uml25-ftf@omg.org" CC: Steve Cook , Ed Willink , "Ed Seidewitz" Subject: AW: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/k2m3Ck2zYR0q/pfIWvIRFOJjRFAeAgAAEWgCAAAkJAIAAOE5g Date: Thu, 11 Apr 2013 18:41:33 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [195.37.77.169] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml25-ftf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate01-dus with 827B4200031 X-cloud-security: scantime:.2363 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== >Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. I like this one, because the only difference of a DataType instance and an Enumeration instance (decoded in the model as EnumerationLiteral) is that an Enumeration contains a finite and prescribed number of instance of itself. Nothing else. Marc-Florian Von: Manfred R. Koethe [mailto:koethe@88solutions.com] Gesendet: Donnerstag, 11. April 2013 19:16 An: uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Betreff: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Are we trying to interpret too much into that? To my understanding, an enumeration is a type with a finite set of discrete and explicitly defined values. That are the EnumerationLiterals, ordinary data values, just created differently than for example a "1" as an Integer data value. Do I miss something? Manfred On Apr 11, 2013, at 9:44 , Ed Seidewitz wrote: Steve -- Except that is kind of pointless, isn't it? The instance of ANY metaclass is "equal to itself and not equal to anything other than itself" (since instances of metaclasses are objects with identity). The sentence being replaced talks about the "run-time value representing an EnumerationLiteral", and this appears under "Semantics". So, clearly, what is under discussion is the M0 meaning of an EnumerationLiteral as representing a data value of its Enumeration, not the M1 instance of the metaclass EnumerationLiteral. While I agree that "object memory address" does not really have a meaning for UML, I think that "EnumerationLiteral value" DOES having a meaning, and is exactly what is being referenced here when the text talks about "equality" and "immutability". This is in the same sense in which objects are value as instances of classes and data values are values as instances of data types -- it is just that, in the case of an Enumeration, we happen to have EnumerationLiteral model elements that directly represent the explicitly enumerated instances of the Enumeration. (This is explicit in the fUML Execution Model, by the way, in which there may be multiple EnumerationLiteralValues that point to the same M1 EnumerationLiteral, but any two EnumerationLiteralValues for the same EnumerationLiteral are considered to be equal.) -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, April 11, 2013 12:28 PM To: Ed Willink; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: Steve Cook To: "Wendland, Marc-Florian" , "Manfred R. Koethe" , "uml25-ftf@omg.org" CC: Ed Willink , Ed Seidewitz Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/mYUDCX6Lw3EiryquvTAL6/pjRNFCggAAFmACAAAkJAIAAF8+AgAEGogA= Date: Fri, 12 Apr 2013 10:44:08 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(24454001)(189002)(199002)(52034002)(13464002)(51444002)(5403001)(377454001)(74662001)(54316002)(53806001)(51856001)(71186001)(56776001)(564824004)(20776003)(77982001)(47976001)(59766001)(76482001)(50986001)(18277545001)(33656001)(80022001)(16236675001)(44976002)(46102001)(18276755001)(63696002)(16601075001)(81542001)(5343635001)(31966008)(65816001)(74502001)(47736001)(55846006)(5343655001)(16406001)(15202345001)(79102001)(49866001)(47446002)(69226001)(4396001)(512954001)(56816002)(54356001)(81342001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB003;H:TK5EX14HUBC104.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0814A2C7A3 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== I cannot agree with Ed that the distinction I made is pointless. InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values, even if they are different objects. UML does have expressions; those expressions may refer to EnumerationLiterals via InstanceValues; and any two expressions referring to the same EnumerationLiteral must refer to the exact same object. This happens a lot, for default values, in UML models; and these cases the semantics do apply to M1 instances. And the idea of delegating to datatype equality by deep value equivalence doesn.t make much sense to me for EnumerationLiterals: indeed, for the M1 case I think it would be very misleading. Nevertheless, I am open to rephrasing this if people are unhappy. How about replacing .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by .Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. This is intended to cover both the M0 and M1 cases. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 11 April 2013 19:42 To: Manfred R. Koethe; uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Subject: AW: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes >Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. I like this one, because the only difference of a DataType instance and an Enumeration instance (decoded in the model as EnumerationLiteral) is that an Enumeration contains a finite and prescribed number of instance of itself. Nothing else. Marc-Florian Von: Manfred R. Koethe [mailto:koethe@88solutions.com] Gesendet: Donnerstag, 11. April 2013 19:16 An: uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Betreff: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Are we trying to interpret too much into that? To my understanding, an enumeration is a type with a finite set of discrete and explicitly defined values. That are the EnumerationLiterals, ordinary data values, just created differently than for example a "1" as an Integer data value. Do I miss something? Manfred On Apr 11, 2013, at 9:44 , Ed Seidewitz wrote: Steve -- Except that is kind of pointless, isn't it? The instance of ANY metaclass is "equal to itself and not equal to anything other than itself" (since instances of metaclasses are objects with identity). The sentence being replaced talks about the "run-time value representing an EnumerationLiteral", and this appears under "Semantics". So, clearly, what is under discussion is the M0 meaning of an EnumerationLiteral as representing a data value of its Enumeration, not the M1 instance of the metaclass EnumerationLiteral. While I agree that "object memory address" does not really have a meaning for UML, I think that "EnumerationLiteral value" DOES having a meaning, and is exactly what is being referenced here when the text talks about "equality" and "immutability". This is in the same sense in which objects are value as instances of classes and data values are values as instances of data types -- it is just that, in the case of an Enumeration, we happen to have EnumerationLiteral model elements that directly represent the explicitly enumerated instances of the Enumeration. (This is explicit in the fUML Execution Model, by the way, in which there may be multiple EnumerationLiteralValues that point to the same M1 EnumerationLiteral, but any two EnumerationLiteralValues for the same EnumerationLiteral are considered to be equal.) -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, April 11, 2013 12:28 PM To: Ed Willink; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- X-Virus-Scanned: OK From: Ed Seidewitz To: Steve Cook CC: Ed Willink , "Wendland, Marc-Florian" , "Manfred R. Koethe" , "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/DnWyU9Fk3cEGmdKYiPD1fxZjRiWCA//+tUNCAAGATAIAAF8+AgAEM8QCAACn+MA== Date: Fri, 12 Apr 2013 18:23:13 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.71.243.163] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Gpodelmo X-Brightmail-Tracker: AAAAAA== Steve . I think that the alternative wording you suggest is better. But, just to be pedantic, let me explain why I think it is better! It is not the case that .InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values.. Rather it is instances of DataTypes that are considered equal if the values of features for corresponding attibutes are equal. This is important, as it relates to the reason that InstanceSpecifications are called InstanceSpecifications and not Instances. For example, actions, like TestIdentitiyAction, which formally defines what .equality. means in a UML behavior model, don.t operate on InstanceSpecifications, they operate on instances. Further, the instance (or instances, plural, actually) that an InstanceSpecification may represent depends on the semantic interpretation on gives to the model in which the InstanceSpecification occurs. You can actually have two InstanceSpecifications in two different models that seemingly have the same .values. for corresponding slots, but they may represent entirely different instances (e.g, in one case the instance may be conceptual, while in the other case it may represent a Java object). For a clear definition of semantics, it is always important to separate syntactic representation from semantic interpretation. This is just the classic .numeral vs. number. discussion writ large. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, April 12, 2013 6:44 AM To: Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Cc: Ed Willink; Ed Seidewitz Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes I cannot agree with Ed that the distinction I made is pointless. InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values, even if they are different objects. UML does have expressions; those expressions may refer to EnumerationLiterals via InstanceValues; and any two expressions referring to the same EnumerationLiteral must refer to the exact same object. This happens a lot, for default values, in UML models; and these cases the semantics do apply to M1 instances. And the idea of delegating to datatype equality by deep value equivalence doesn.t make much sense to me for EnumerationLiterals: indeed, for the M1 case I think it would be very misleading. Nevertheless, I am open to rephrasing this if people are unhappy. How about replacing .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by .Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. This is intended to cover both the M0 and M1 cases. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 11 April 2013 19:42 To: Manfred R. Koethe; uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Subject: AW: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes >Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. I like this one, because the only difference of a DataType instance and an Enumeration instance (decoded in the model as EnumerationLiteral) is that an Enumeration contains a finite and prescribed number of instance of itself. Nothing else. Marc-Florian Von: Manfred R. Koethe [mailto:koethe@88solutions.com] Gesendet: Donnerstag, 11. April 2013 19:16 An: uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Betreff: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Are we trying to interpret too much into that? To my understanding, an enumeration is a type with a finite set of discrete and explicitly defined values. That are the EnumerationLiterals, ordinary data values, just created differently than for example a "1" as an Integer data value. Do I miss something? Manfred On Apr 11, 2013, at 9:44 , Ed Seidewitz wrote: Steve -- Except that is kind of pointless, isn't it? The instance of ANY metaclass is "equal to itself and not equal to anything other than itself" (since instances of metaclasses are objects with identity). The sentence being replaced talks about the "run-time value representing an EnumerationLiteral", and this appears under "Semantics". So, clearly, what is under discussion is the M0 meaning of an EnumerationLiteral as representing a data value of its Enumeration, not the M1 instance of the metaclass EnumerationLiteral. While I agree that "object memory address" does not really have a meaning for UML, I think that "EnumerationLiteral value" DOES having a meaning, and is exactly what is being referenced here when the text talks about "equality" and "immutability". This is in the same sense in which objects are value as instances of classes and data values are values as instances of data types -- it is just that, in the case of an Enumeration, we happen to have EnumerationLiteral model elements that directly represent the explicitly enumerated instances of the Enumeration. (This is explicit in the fUML Execution Model, by the way, in which there may be multiple EnumerationLiteralValues that point to the same M1 EnumerationLiteral, but any two EnumerationLiteralValues for the same EnumerationLiteral are considered to be equal.) -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, April 11, 2013 12:28 PM To: Ed Willink; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: Steve Cook To: "Manfred R. Koethe" CC: "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/mYUDCX6Lw3EiryquvTAL6/pjRNFCggAAFmACAAAkJAIAAF8+AgAEGogCAAIaUgIABWTKQ Date: Sat, 13 Apr 2013 15:08:36 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(377454001)(24454001)(5403001)(13464002)(199002)(51444002)(189002)(52034002)(51856001)(31966008)(54316002)(74662001)(74502001)(71186001)(15202345001)(56776001)(54356001)(16236675001)(69226001)(5343635001)(5343655001)(59766001)(55846006)(80022001)(76482001)(16406001)(44976002)(53806001)(65816001)(56816002)(50986001)(47976001)(33656001)(47446002)(49866001)(16601075001)(47736001)(564824004)(81342001)(79102001)(46102001)(18276755001)(20776003)(512954001)(81542001)(18277545001)(4396001)(77982001)(63696002);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB014;H:TK5EX14HUBC107.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0815F8251E X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== Manfred Can you amend the proposed resolution for 8274 please: replace .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by .Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. Ed, I agree with everything you say, but it remains the case that a UML model might possibly contain two different InstanceSpecifications classified as DataTypes, both referred to by InstanceValues, with the same slot values, participating in an equality comparison expression, and I.d expect the semantic function for such an expression to produce true (insofar as such a situation has any semantics at all). Such is not the case for EnumerationLiterals, which may only have a single representation in a model, namely the one owned by the Enumeration. That.s the only distinction I am making. -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 12 April 2013 19:23 To: Steve Cook Cc: Ed Willink; Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Steve . I think that the alternative wording you suggest is better. But, just to be pedantic, let me explain why I think it is better! It is not the case that .InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values.. Rather it is instances of DataTypes that are considered equal if the values of features for corresponding attibutes are equal. This is important, as it relates to the reason that InstanceSpecifications are called InstanceSpecifications and not Instances. For example, actions, like TestIdentitiyAction, which formally defines what .equality. means in a UML behavior model, don.t operate on InstanceSpecifications, they operate on instances. Further, the instance (or instances, plural, actually) that an InstanceSpecification may represent depends on the semantic interpretation on gives to the model in which the InstanceSpecification occurs. You can actually have two InstanceSpecifications in two different models that seemingly have the same .values. for corresponding slots, but they may represent entirely different instances (e.g, in one case the instance may be conceptual, while in the other case it may represent a Java object). For a clear definition of semantics, it is always important to separate syntactic representation from semantic interpretation. This is just the classic .numeral vs. number. discussion writ large. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, April 12, 2013 6:44 AM To: Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Cc: Ed Willink; Ed Seidewitz Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes I cannot agree with Ed that the distinction I made is pointless. InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values, even if they are different objects. UML does have expressions; those expressions may refer to EnumerationLiterals via InstanceValues; and any two expressions referring to the same EnumerationLiteral must refer to the exact same object. This happens a lot, for default values, in UML models; and these cases the semantics do apply to M1 instances. And the idea of delegating to datatype equality by deep value equivalence doesn.t make much sense to me for EnumerationLiterals: indeed, for the M1 case I think it would be very misleading. Nevertheless, I am open to rephrasing this if people are unhappy. How about replacing .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by .Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. This is intended to cover both the M0 and M1 cases. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 11 April 2013 19:42 To: Manfred R. Koethe; uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Subject: AW: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes >Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. I like this one, because the only difference of a DataType instance and an Enumeration instance (decoded in the model as EnumerationLiteral) is that an Enumeration contains a finite and prescribed number of instance of itself. Nothing else. Marc-Florian Von: Manfred R. Koethe [mailto:koethe@88solutions.com] Gesendet: Donnerstag, 11. April 2013 19:16 An: uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Betreff: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Are we trying to interpret too much into that? To my understanding, an enumeration is a type with a finite set of discrete and explicitly defined values. That are the EnumerationLiterals, ordinary data values, just created differently than for example a "1" as an Integer data value. Do I miss something? Manfred On Apr 11, 2013, at 9:44 , Ed Seidewitz wrote: Steve -- Except that is kind of pointless, isn't it? The instance of ANY metaclass is "equal to itself and not equal to anything other than itself" (since instances of metaclasses are objects with identity). The sentence being replaced talks about the "run-time value representing an EnumerationLiteral", and this appears under "Semantics". So, clearly, what is under discussion is the M0 meaning of an EnumerationLiteral as representing a data value of its Enumeration, not the M1 instance of the metaclass EnumerationLiteral. While I agree that "object memory address" does not really have a meaning for UML, I think that "EnumerationLiteral value" DOES having a meaning, and is exactly what is being referenced here when the text talks about "equality" and "immutability". This is in the same sense in which objects are value as instances of classes and data values are values as instances of data types -- it is just that, in the case of an Enumeration, we happen to have EnumerationLiteral model elements that directly represent the explicitly enumerated instances of the Enumeration. (This is explicit in the fUML Execution Model, by the way, in which there may be multiple EnumerationLiteralValues that point to the same M1 EnumerationLiteral, but any two EnumerationLiteralValues for the same EnumerationLiteral are considered to be equal.) -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, April 11, 2013 12:28 PM To: Ed Willink; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- X-Virus-Scanned: OK From: Ed Seidewitz To: Steve Cook , "Manfred R. Koethe" CC: "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/DnWyU9Fk3cEGmdKYiPD1fxZjRiWCA//+tUNCAAGATAIAAF8+AgAEM8QCAACn+MIABsjsAgAGF6vA= Date: Sun, 14 Apr 2013 19:27:02 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.248.124.25] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Gpodelmo X-Brightmail-Tracker: AAAAAA== Steve . Your comment about the representation of enumeration literals isn.t quite right. It is possible to have two different InstanceSpecifications that have specifications that are InstanceValues that both point to the same EnumerationLiteral. The value of the both of these InstanceSpecifications should be the same as the value of the EnumerationLiteral . but they are different representations. (And this indirection can be recursed any number of times . isn.t UML wonderful?!?) -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Saturday, April 13, 2013 11:09 AM To: Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Manfred Can you amend the proposed resolution for 8274 please: replace .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by .Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. Ed, I agree with everything you say, but it remains the case that a UML model might possibly contain two different InstanceSpecifications classified as DataTypes, both referred to by InstanceValues, with the same slot values, participating in an equality comparison expression, and I.d expect the semantic function for such an expression to produce true (insofar as such a situation has any semantics at all). Such is not the case for EnumerationLiterals, which may only have a single representation in a model, namely the one owned by the Enumeration. That.s the only distinction I am making. -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 12 April 2013 19:23 To: Steve Cook Cc: Ed Willink; Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Steve . I think that the alternative wording you suggest is better. But, just to be pedantic, let me explain why I think it is better! It is not the case that .InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values.. Rather it is instances of DataTypes that are considered equal if the values of features for corresponding attibutes are equal. This is important, as it relates to the reason that InstanceSpecifications are called InstanceSpecifications and not Instances. For example, actions, like TestIdentitiyAction, which formally defines what .equality. means in a UML behavior model, don.t operate on InstanceSpecifications, they operate on instances. Further, the instance (or instances, plural, actually) that an InstanceSpecification may represent depends on the semantic interpretation on gives to the model in which the InstanceSpecification occurs. You can actually have two InstanceSpecifications in two different models that seemingly have the same .values. for corresponding slots, but they may represent entirely different instances (e.g, in one case the instance may be conceptual, while in the other case it may represent a Java object). For a clear definition of semantics, it is always important to separate syntactic representation from semantic interpretation. This is just the classic .numeral vs. number. discussion writ large. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, April 12, 2013 6:44 AM To: Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Cc: Ed Willink; Ed Seidewitz Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes I cannot agree with Ed that the distinction I made is pointless. InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values, even if they are different objects. UML does have expressions; those expressions may refer to EnumerationLiterals via InstanceValues; and any two expressions referring to the same EnumerationLiteral must refer to the exact same object. This happens a lot, for default values, in UML models; and these cases the semantics do apply to M1 instances. And the idea of delegating to datatype equality by deep value equivalence doesn.t make much sense to me for EnumerationLiterals: indeed, for the M1 case I think it would be very misleading. Nevertheless, I am open to rephrasing this if people are unhappy. How about replacing .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by .Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. This is intended to cover both the M0 and M1 cases. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 11 April 2013 19:42 To: Manfred R. Koethe; uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Subject: AW: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes >Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. I like this one, because the only difference of a DataType instance and an Enumeration instance (decoded in the model as EnumerationLiteral) is that an Enumeration contains a finite and prescribed number of instance of itself. Nothing else. Marc-Florian Von: Manfred R. Koethe [mailto:koethe@88solutions.com] Gesendet: Donnerstag, 11. April 2013 19:16 An: uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Betreff: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Are we trying to interpret too much into that? To my understanding, an enumeration is a type with a finite set of discrete and explicitly defined values. That are the EnumerationLiterals, ordinary data values, just created differently than for example a "1" as an Integer data value. Do I miss something? Manfred On Apr 11, 2013, at 9:44 , Ed Seidewitz wrote: Steve -- Except that is kind of pointless, isn't it? The instance of ANY metaclass is "equal to itself and not equal to anything other than itself" (since instances of metaclasses are objects with identity). The sentence being replaced talks about the "run-time value representing an EnumerationLiteral", and this appears under "Semantics". So, clearly, what is under discussion is the M0 meaning of an EnumerationLiteral as representing a data value of its Enumeration, not the M1 instance of the metaclass EnumerationLiteral. While I agree that "object memory address" does not really have a meaning for UML, I think that "EnumerationLiteral value" DOES having a meaning, and is exactly what is being referenced here when the text talks about "equality" and "immutability". This is in the same sense in which objects are value as instances of classes and data values are values as instances of data types -- it is just that, in the case of an Enumeration, we happen to have EnumerationLiteral model elements that directly represent the explicitly enumerated instances of the Enumeration. (This is explicit in the fUML Execution Model, by the way, in which there may be multiple EnumerationLiteralValues that point to the same M1 EnumerationLiteral, but any two EnumerationLiteralValues for the same EnumerationLiteral are considered to be equal.) -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, April 11, 2013 12:28 PM To: Ed Willink; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: Steve Cook To: Ed Seidewitz , "Manfred R. Koethe" CC: "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/mYUDCX6Lw3EiryquvTAL6/pjRNFCggAAFmACAAAkJAIAAF8+AgAEGogCAAIaUgIABWTKQgAHdTACAANhLoA== Date: Mon, 15 Apr 2013 08:22:23 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(52034002)(199002)(189002)(24454001)(377454001)(13464002)(51444002)(5403001)(18277545001)(56776001)(20776003)(31966008)(16601075002)(76482001)(53806001)(47736001)(56816002)(74662001)(69226001)(63696002)(15202345002)(33656001)(65816001)(71186001)(4396001)(77982001)(5343655001)(49866001)(50986001)(54316002)(46102001)(47446002)(81542001)(55846006)(5343635001)(80022001)(79102001)(74502001)(564824004)(54356001)(47976001)(59766001)(81342001)(512954001)(16236675002)(44976003)(16406001)(18276755001)(51856001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB025;H:TK5EX14MLTC102.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 X-Virus-Scanned: amavisd-new at omg.org Ah, I hadn.t thought of that. >isn.t UML wonderful?!? For some values of .wonderful., perhaps. From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 14 April 2013 20:27 To: Steve Cook; Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Steve . Your comment about the representation of enumeration literals isn.t quite right. It is possible to have two different InstanceSpecifications that have specifications that are InstanceValues that both point to the same EnumerationLiteral. The value of the both of these InstanceSpecifications should be the same as the value of the EnumerationLiteral . but they are different representations. (And this indirection can be recursed any number of times . isn.t UML wonderful?!?) -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Saturday, April 13, 2013 11:09 AM To: Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Manfred Can you amend the proposed resolution for 8274 please: replace .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by .Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. Ed, I agree with everything you say, but it remains the case that a UML model might possibly contain two different InstanceSpecifications classified as DataTypes, both referred to by InstanceValues, with the same slot values, participating in an equality comparison expression, and I.d expect the semantic function for such an expression to produce true (insofar as such a situation has any semantics at all). Such is not the case for EnumerationLiterals, which may only have a single representation in a model, namely the one owned by the Enumeration. That.s the only distinction I am making. -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 12 April 2013 19:23 To: Steve Cook Cc: Ed Willink; Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Steve . I think that the alternative wording you suggest is better. But, just to be pedantic, let me explain why I think it is better! It is not the case that .InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values.. Rather it is instances of DataTypes that are considered equal if the values of features for corresponding attibutes are equal. This is important, as it relates to the reason that InstanceSpecifications are called InstanceSpecifications and not Instances. For example, actions, like TestIdentitiyAction, which formally defines what .equality. means in a UML behavior model, don.t operate on InstanceSpecifications, they operate on instances. Further, the instance (or instances, plural, actually) that an InstanceSpecification may represent depends on the semantic interpretation on gives to the model in which the InstanceSpecification occurs. You can actually have two InstanceSpecifications in two different models that seemingly have the same .values. for corresponding slots, but they may represent entirely different instances (e.g, in one case the instance may be conceptual, while in the other case it may represent a Java object). For a clear definition of semantics, it is always important to separate syntactic representation from semantic interpretation. This is just the classic .numeral vs. number. discussion writ large. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, April 12, 2013 6:44 AM To: Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Cc: Ed Willink; Ed Seidewitz Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes I cannot agree with Ed that the distinction I made is pointless. InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values, even if they are different objects. UML does have expressions; those expressions may refer to EnumerationLiterals via InstanceValues; and any two expressions referring to the same EnumerationLiteral must refer to the exact same object. This happens a lot, for default values, in UML models; and these cases the semantics do apply to M1 instances. And the idea of delegating to datatype equality by deep value equivalence doesn.t make much sense to me for EnumerationLiterals: indeed, for the M1 case I think it would be very misleading. Nevertheless, I am open to rephrasing this if people are unhappy. How about replacing .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by .Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. This is intended to cover both the M0 and M1 cases. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 11 April 2013 19:42 To: Manfred R. Koethe; uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Subject: AW: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes >Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. I like this one, because the only difference of a DataType instance and an Enumeration instance (decoded in the model as EnumerationLiteral) is that an Enumeration contains a finite and prescribed number of instance of itself. Nothing else. Marc-Florian Von: Manfred R. Koethe [mailto:koethe@88solutions.com] Gesendet: Donnerstag, 11. April 2013 19:16 An: uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Betreff: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Are we trying to interpret too much into that? To my understanding, an enumeration is a type with a finite set of discrete and explicitly defined values. That are the EnumerationLiterals, ordinary data values, just created differently than for example a "1" as an Integer data value. Do I miss something? Manfred On Apr 11, 2013, at 9:44 , Ed Seidewitz wrote: Steve -- Except that is kind of pointless, isn't it? The instance of ANY metaclass is "equal to itself and not equal to anything other than itself" (since instances of metaclasses are objects with identity). The sentence being replaced talks about the "run-time value representing an EnumerationLiteral", and this appears under "Semantics". So, clearly, what is under discussion is the M0 meaning of an EnumerationLiteral as representing a data value of its Enumeration, not the M1 instance of the metaclass EnumerationLiteral. While I agree that "object memory address" does not really have a meaning for UML, I think that "EnumerationLiteral value" DOES having a meaning, and is exactly what is being referenced here when the text talks about "equality" and "immutability". This is in the same sense in which objects are value as instances of classes and data values are values as instances of data types -- it is just that, in the case of an Enumeration, we happen to have EnumerationLiteral model elements that directly represent the explicitly enumerated instances of the Enumeration. (This is explicit in the fUML Execution Model, by the way, in which there may be multiple EnumerationLiteralValues that point to the same M1 EnumerationLiteral, but any two EnumerationLiteralValues for the same EnumerationLiteral are considered to be equal.) -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, April 11, 2013 12:28 PM To: Ed Willink; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: "Rouquette, Nicolas F (313K)" To: Steve Cook , "Manfred R. Koethe" CC: "uml25-ftf@omg.org" Subject: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/TPJl/HHm5oEmAls4KFmW8kZjRqueAgAAEWgCAAAkJAIAAF8+AgAEM8QCAAIBFgIABW/QAgArr3gA= Date: Sat, 20 Apr 2013 20:55:26 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org .Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. This is wording is misleading for an Enumeration that has an EnumerationLiteral specified by a ValueSpecification. Does "value" above refer to an EnumerationLiteral (it's an InstanceSpecification, not a ValueSpecification) or to the specification of the value of an EnumerationLiteral? I think we need to be careful in keeping the flexibility we currently have to do something like this: Enumeration Sizes1 specializes Integer { EnumerationLiteral Small { specification = Interval { min = 0; max = 10 }} EnumerationLiteral Medium { specification = Interval { min = 10; max = 100 }} EnumerationLiteral Large { specification = Interval { min = 100; max = +Inf }} } Class A { property x : Sizes1; } Enumeration Sizes2 specializes Integer { EnumerationLiteral Small { specification = LiteralInteger { value = 0 }} EnumerationLiteral Medium { specification = LiteralInteger { value = 10 }} EnumerationLiteral Large { specification = LiteralInteger { value = 100 }} } Class B { property x : Sizes2; } Per current UML, Sizes1's and Sizes2's literals are the only values that I can use respectively for the default value of A::x or B::x or for a WriteStructuralFeatureAction to update respectively A::x or B::x. Unfortunately, UML does not provide any support for user to specify how values (e.g., 42) map into corresponding EnumerationLiterals (e.g., Sizes1::Medium or Sizes2::Medium) Nicolas. From: Steve Cook Date: Saturday, April 13, 2013 8:08 AM To: Manfred Koethe Cc: "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Manfred Can you amend the proposed resolution for 8274 please: replace .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by.Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. Ed, I agree with everything you say, but it remains the case that a UML model might possibly contain two different InstanceSpecifications classified as DataTypes, both referred to by InstanceValues, with the same slot values, participating in an equality comparison expression, and I.d expect the semantic function for such an expression to produce true (insofar as such a situation has any semantics at all). Such is not the case for EnumerationLiterals, which may only have a single representation in a model, namely the one owned by the Enumeration. That.s the only distinction I am making. -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 12 April 2013 19:23 To: Steve Cook Cc: Ed Willink; Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Steve . I think that the alternative wording you suggest is better. But, just to be pedantic, let me explain why I think it is better! It is not the case that .InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values.. Rather it is instances of DataTypes that are considered equal if the values of features for corresponding attibutes are equal. This is important, as it relates to the reason that InstanceSpecifications are called InstanceSpecifications and not Instances. For example, actions, like TestIdentitiyAction, which formally defines what .equality. means in a UML behavior model, don.t operate on InstanceSpecifications, they operate on instances. Further, the instance (or instances, plural, actually) that an InstanceSpecification may represent depends on the semantic interpretation on gives to the model in which the InstanceSpecification occurs. You can actually have two InstanceSpecifications in two different models that seemingly have the same .values. for corresponding slots, but they may represent entirely different instances (e.g, in one case the instance may be conceptual, while in the other case it may represent a Java object). For a clear definition of semantics, it is always important to separate syntactic representation from semantic interpretation. This is just the classic .numeral vs. number. discussion writ large. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, April 12, 2013 6:44 AM To: Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Cc: Ed Willink; Ed Seidewitz Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes I cannot agree with Ed that the distinction I made is pointless. InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values, even if they are different objects. UML does have expressions; those expressions may refer to EnumerationLiterals via InstanceValues; and any two expressions referring to the same EnumerationLiteral must refer to the exact same object. This happens a lot, for default values, in UML models; and these cases the semantics do apply to M1 instances. And the idea of delegating to datatype equality by deep value equivalence doesn.t make much sense to me for EnumerationLiterals: indeed, for the M1 case I think it would be very misleading. Nevertheless, I am open to rephrasing this if people are unhappy. How about replacing .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by.Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. This is intended to cover both the M0 and M1 cases. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 11 April 2013 19:42 To: Manfred R. Koethe; uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Subject: AW: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes >Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. I like this one, because the only difference of a DataType instance and an Enumeration instance (decoded in the model as EnumerationLiteral) is that an Enumeration contains a finite and prescribed number of instance of itself. Nothing else. Marc-Florian Von: Manfred R. Koethe [mailto:koethe@88solutions.com] Gesendet: Donnerstag, 11. April 2013 19:16 An: uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Betreff: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Are we trying to interpret too much into that? To my understanding, an enumeration is a type with a finite set of discrete and explicitly defined values. That are the EnumerationLiterals, ordinary data values, just created differently than for example a "1" as an Integer data value. Do I miss something? Manfred On Apr 11, 2013, at 9:44 , Ed Seidewitz wrote: Steve -- Except that is kind of pointless, isn't it? The instance of ANY metaclass is "equal to itself and not equal to anything other than itself" (since instances of metaclasses are objects with identity). The sentence being replaced talks about the "run-time value representing an EnumerationLiteral", and this appears under "Semantics". So, clearly, what is under discussion is the M0 meaning of an EnumerationLiteral as representing a data value of its Enumeration, not the M1 instance of the metaclass EnumerationLiteral. While I agree that "object memory address" does not really have a meaning for UML, I think that "EnumerationLiteral value" DOES having a meaning, and is exactly what is being referenced here when the text talks about "equality" and "immutability". This is in the same sense in which objects are value as instances of classes and data values are values as instances of data types -- it is just that, in the case of an Enumeration, we happen to have EnumerationLiteral model elements that directly represent the explicitly enumerated instances of the Enumeration. (This is explicit in the fUML Execution Model, by the way, in which there may be multiple EnumerationLiteralValues that point to the same M1 EnumerationLiteral, but any two EnumerationLiteralValues for the same EnumerationLiteral are considered to be equal.) -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, April 11, 2013 12:28 PM To: Ed Willink; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: Steve Cook To: "Rouquette, Nicolas F (313K)" , "Manfred R. Koethe" CC: "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/mYUDCX6Lw3EiryquvTAL6/pjRNFCggAAFmACAAAkJAIAAF8+AgAEGogCAAIaUgIABWTKQgAtj/ACABBZvEA== Date: Tue, 23 Apr 2013 11:33:10 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(24454001)(13464002)(52034002)(5403001)(51444002)(199002)(189002)(377454001)(56816002)(63696002)(56776001)(79102001)(33656001)(65816001)(6806003)(46102001)(59766001)(54316002)(55846006)(53806001)(76482001)(16406001)(4396001)(16236675002)(80022001)(81342001)(15202345002)(50986001)(47736001)(564824004)(74502001)(47976001)(20776003)(77982001)(49866001)(74662001)(51856001)(71186001)(31966008)(16796002)(47446002)(44976003)(81542001)(512954001)(54356001)(16601075002)(69226001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB040;H:TK5EX14HUBC107.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08252193F3 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== Nicolas The intention is certainly not to exclude your example, and I don.t really see how it does. The value of Sizes1::Small would be some semantic construct that would be equal to the value of Sizes1::Small and not equal to anything else (including the value of Sizes2::Small). The meaning of .values corresponding to literal. in the proposed resolution is supposed to be .values (in the semantic domain) denoting literal (in the syntactic domain)., using the terminology of denotational semantics. But I can see that the words .corresponding to. may be subject to some ambiguity. .Denoted by. seems very specialized, especially since the word .denote. has an approximately opposite meaning in its conventional sense to its meaning in the world of denotational semantics. How about .values modeled by literal. or .values represented by literal.? Maybe we can decide on this during today.s call. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 20 April 2013 21:55 To: Steve Cook; Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes .Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. This is wording is misleading for an Enumeration that has an EnumerationLiteral specified by a ValueSpecification. Does "value" above refer to an EnumerationLiteral (it's an InstanceSpecification, not a ValueSpecification) or to the specification of the value of an EnumerationLiteral? I think we need to be careful in keeping the flexibility we currently have to do something like this: Enumeration Sizes1 specializes Integer { EnumerationLiteral Small { specification = Interval { min = 0; max = 10 }} EnumerationLiteral Medium { specification = Interval { min = 10; max = 100 }} EnumerationLiteral Large { specification = Interval { min = 100; max = +Inf }} } Class A { property x : Sizes1; } Enumeration Sizes2 specializes Integer { EnumerationLiteral Small { specification = LiteralInteger { value = 0 }} EnumerationLiteral Medium { specification = LiteralInteger { value = 10 }} EnumerationLiteral Large { specification = LiteralInteger { value = 100 }} } Class B { property x : Sizes2; } Per current UML, Sizes1's and Sizes2's literals are the only values that I can use respectively for the default value of A::x or B::x or for a WriteStructuralFeatureAction to update respectively A::x or B::x. Unfortunately, UML does not provide any support for user to specify how values (e.g., 42) map into corresponding EnumerationLiterals (e.g., Sizes1::Medium or Sizes2::Medium) Nicolas. From: Steve Cook Date: Saturday, April 13, 2013 8:08 AM To: Manfred Koethe Cc: "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Manfred Can you amend the proposed resolution for 8274 please: replace .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by.Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. Ed, I agree with everything you say, but it remains the case that a UML model might possibly contain two different InstanceSpecifications classified as DataTypes, both referred to by InstanceValues, with the same slot values, participating in an equality comparison expression, and I.d expect the semantic function for such an expression to produce true (insofar as such a situation has any semantics at all). Such is not the case for EnumerationLiterals, which may only have a single representation in a model, namely the one owned by the Enumeration. That.s the only distinction I am making. -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 12 April 2013 19:23 To: Steve Cook Cc: Ed Willink; Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Steve . I think that the alternative wording you suggest is better. But, just to be pedantic, let me explain why I think it is better! It is not the case that .InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values.. Rather it is instances of DataTypes that are considered equal if the values of features for corresponding attibutes are equal. This is important, as it relates to the reason that InstanceSpecifications are called InstanceSpecifications and not Instances. For example, actions, like TestIdentitiyAction, which formally defines what .equality. means in a UML behavior model, don.t operate on InstanceSpecifications, they operate on instances. Further, the instance (or instances, plural, actually) that an InstanceSpecification may represent depends on the semantic interpretation on gives to the model in which the InstanceSpecification occurs. You can actually have two InstanceSpecifications in two different models that seemingly have the same .values. for corresponding slots, but they may represent entirely different instances (e.g, in one case the instance may be conceptual, while in the other case it may represent a Java object). For a clear definition of semantics, it is always important to separate syntactic representation from semantic interpretation. This is just the classic .numeral vs. number. discussion writ large. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, April 12, 2013 6:44 AM To: Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Cc: Ed Willink; Ed Seidewitz Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes I cannot agree with Ed that the distinction I made is pointless. InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values, even if they are different objects. UML does have expressions; those expressions may refer to EnumerationLiterals via InstanceValues; and any two expressions referring to the same EnumerationLiteral must refer to the exact same object. This happens a lot, for default values, in UML models; and these cases the semantics do apply to M1 instances. And the idea of delegating to datatype equality by deep value equivalence doesn.t make much sense to me for EnumerationLiterals: indeed, for the M1 case I think it would be very misleading. Nevertheless, I am open to rephrasing this if people are unhappy. How about replacing .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by.Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. This is intended to cover both the M0 and M1 cases. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 11 April 2013 19:42 To: Manfred R. Koethe; uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Subject: AW: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes >Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. I like this one, because the only difference of a DataType instance and an Enumeration instance (decoded in the model as EnumerationLiteral) is that an Enumeration contains a finite and prescribed number of instance of itself. Nothing else. Marc-Florian Von: Manfred R. Koethe [mailto:koethe@88solutions.com] Gesendet: Donnerstag, 11. April 2013 19:16 An: uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Betreff: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Are we trying to interpret too much into that? To my understanding, an enumeration is a type with a finite set of discrete and explicitly defined values. That are the EnumerationLiterals, ordinary data values, just created differently than for example a "1" as an Integer data value. Do I miss something? Manfred On Apr 11, 2013, at 9:44 , Ed Seidewitz wrote: Steve -- Except that is kind of pointless, isn't it? The instance of ANY metaclass is "equal to itself and not equal to anything other than itself" (since instances of metaclasses are objects with identity). The sentence being replaced talks about the "run-time value representing an EnumerationLiteral", and this appears under "Semantics". So, clearly, what is under discussion is the M0 meaning of an EnumerationLiteral as representing a data value of its Enumeration, not the M1 instance of the metaclass EnumerationLiteral. While I agree that "object memory address" does not really have a meaning for UML, I think that "EnumerationLiteral value" DOES having a meaning, and is exactly what is being referenced here when the text talks about "equality" and "immutability". This is in the same sense in which objects are value as instances of classes and data values are values as instances of data types -- it is just that, in the case of an Enumeration, we happen to have EnumerationLiteral model elements that directly represent the explicitly enumerated instances of the Enumeration. (This is explicit in the fUML Execution Model, by the way, in which there may be multiple EnumerationLiteralValues that point to the same M1 EnumerationLiteral, but any two EnumerationLiteralValues for the same EnumerationLiteral are considered to be equal.) -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, April 11, 2013 12:28 PM To: Ed Willink; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: "Rouquette, Nicolas F (313K)" To: Steve Cook , "Manfred R. Koethe" CC: "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/TPJl/HHm5oEmAls4KFmW8kZjRqueAgAAEWgCAAAkJAIAAF8+AgAEM8QCAAIBFgIABW/QAgArr3gCABI9CAP//weFA Date: Tue, 23 Apr 2013 14:53:39 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== Unfortunately, I can.t make the telecom today. However, as long as the example I gave is supported; I.m cool. For the wording, I hope that Ed.s proficiency in English will properly explain the difference between the two uses of values for EnumerationLiterals. I don.t think it.s wise to be silent about this distinction because someone will notice that an EnumerationLiteral can have an EnumerationLiteral::specification : ValueSpecification. So the potential for confusion or ambiguity about the meaning of the spec is definitely there. - Nicolas. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, April 23, 2013 4:33 AM To: Rouquette, Nicolas F (313K); Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Nicolas The intention is certainly not to exclude your example, and I don.t really see how it does. The value of Sizes1::Small would be some semantic construct that would be equal to the value of Sizes1::Small and not equal to anything else (including the value of Sizes2::Small). The meaning of .values corresponding to literal. in the proposed resolution is supposed to be .values (in the semantic domain) denoting literal (in the syntactic domain)., using the terminology of denotational semantics. But I can see that the words .corresponding to. may be subject to some ambiguity. .Denoted by. seems very specialized, especially since the word .denote. has an approximately opposite meaning in its conventional sense to its meaning in the world of denotational semantics. How about .values modeled by literal. or .values represented by literal.? Maybe we can decide on this during today.s call. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 20 April 2013 21:55 To: Steve Cook; Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes .Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. This is wording is misleading for an Enumeration that has an EnumerationLiteral specified by a ValueSpecification. Does "value" above refer to an EnumerationLiteral (it's an InstanceSpecification, not a ValueSpecification) or to the specification of the value of an EnumerationLiteral? I think we need to be careful in keeping the flexibility we currently have to do something like this: Enumeration Sizes1 specializes Integer { EnumerationLiteral Small { specification = Interval { min = 0; max = 10 }} EnumerationLiteral Medium { specification = Interval { min = 10; max = 100 }} EnumerationLiteral Large { specification = Interval { min = 100; max = +Inf }} } Class A { property x : Sizes1; } Enumeration Sizes2 specializes Integer { EnumerationLiteral Small { specification = LiteralInteger { value = 0 }} EnumerationLiteral Medium { specification = LiteralInteger { value = 10 }} EnumerationLiteral Large { specification = LiteralInteger { value = 100 }} } Class B { property x : Sizes2; } Per current UML, Sizes1's and Sizes2's literals are the only values that I can use respectively for the default value of A::x or B::x or for a WriteStructuralFeatureAction to update respectively A::x or B::x. Unfortunately, UML does not provide any support for user to specify how values (e.g., 42) map into corresponding EnumerationLiterals (e.g., Sizes1::Medium or Sizes2::Medium) Nicolas. From: Steve Cook Date: Saturday, April 13, 2013 8:08 AM To: Manfred Koethe Cc: "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Manfred Can you amend the proposed resolution for 8274 please: replace .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by.Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. Ed, I agree with everything you say, but it remains the case that a UML model might possibly contain two different InstanceSpecifications classified as DataTypes, both referred to by InstanceValues, with the same slot values, participating in an equality comparison expression, and I.d expect the semantic function for such an expression to produce true (insofar as such a situation has any semantics at all). Such is not the case for EnumerationLiterals, which may only have a single representation in a model, namely the one owned by the Enumeration. That.s the only distinction I am making. -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 12 April 2013 19:23 To: Steve Cook Cc: Ed Willink; Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Steve . I think that the alternative wording you suggest is better. But, just to be pedantic, let me explain why I think it is better! It is not the case that .InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values.. Rather it is instances of DataTypes that are considered equal if the values of features for corresponding attibutes are equal. This is important, as it relates to the reason that InstanceSpecifications are called InstanceSpecifications and not Instances. For example, actions, like TestIdentitiyAction, which formally defines what .equality. means in a UML behavior model, don.t operate on InstanceSpecifications, they operate on instances. Further, the instance (or instances, plural, actually) that an InstanceSpecification may represent depends on the semantic interpretation on gives to the model in which the InstanceSpecification occurs. You can actually have two InstanceSpecifications in two different models that seemingly have the same .values. for corresponding slots, but they may represent entirely different instances (e.g, in one case the instance may be conceptual, while in the other case it may represent a Java object). For a clear definition of semantics, it is always important to separate syntactic representation from semantic interpretation. This is just the classic .numeral vs. number. discussion writ large. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, April 12, 2013 6:44 AM To: Wendland, Marc-Florian; Manfred R. Koethe; uml25-ftf@omg.org Cc: Ed Willink; Ed Seidewitz Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes I cannot agree with Ed that the distinction I made is pointless. InstanceSpecifications classified by DataTypes will be considered equal if their slots have the same values, even if they are different objects. UML does have expressions; those expressions may refer to EnumerationLiterals via InstanceValues; and any two expressions referring to the same EnumerationLiteral must refer to the exact same object. This happens a lot, for default values, in UML models; and these cases the semantics do apply to M1 instances. And the idea of delegating to datatype equality by deep value equivalence doesn.t make much sense to me for EnumerationLiterals: indeed, for the M1 case I think it would be very misleading. Nevertheless, I am open to rephrasing this if people are unhappy. How about replacing .EnumerationLiterals may be compared for equality; an EnumerationLiteral is equal to itself and not equal to anything other than itself. by.Values corresponding to EnumerationLiterals are immutable and may be compared for equality; all values corresponding to a particular EnumerationLiteral are equal to each other and not equal to any other values.. This is intended to cover both the M0 and M1 cases. -- Steve From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: 11 April 2013 19:42 To: Manfred R. Koethe; uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Subject: AW: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes >Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. I like this one, because the only difference of a DataType instance and an Enumeration instance (decoded in the model as EnumerationLiteral) is that an Enumeration contains a finite and prescribed number of instance of itself. Nothing else. Marc-Florian Von: Manfred R. Koethe [mailto:koethe@88solutions.com] Gesendet: Donnerstag, 11. April 2013 19:16 An: uml25-ftf@omg.org Cc: Steve Cook; Ed Willink; Ed Seidewitz Betreff: Re: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Are we trying to interpret too much into that? To my understanding, an enumeration is a type with a finite set of discrete and explicitly defined values. That are the EnumerationLiterals, ordinary data values, just created differently than for example a "1" as an Integer data value. Do I miss something? Manfred On Apr 11, 2013, at 9:44 , Ed Seidewitz wrote: Steve -- Except that is kind of pointless, isn't it? The instance of ANY metaclass is "equal to itself and not equal to anything other than itself" (since instances of metaclasses are objects with identity). The sentence being replaced talks about the "run-time value representing an EnumerationLiteral", and this appears under "Semantics". So, clearly, what is under discussion is the M0 meaning of an EnumerationLiteral as representing a data value of its Enumeration, not the M1 instance of the metaclass EnumerationLiteral. While I agree that "object memory address" does not really have a meaning for UML, I think that "EnumerationLiteral value" DOES having a meaning, and is exactly what is being referenced here when the text talks about "equality" and "immutability". This is in the same sense in which objects are value as instances of classes and data values are values as instances of data types -- it is just that, in the case of an Enumeration, we happen to have EnumerationLiteral model elements that directly represent the explicitly enumerated instances of the Enumeration. (This is explicit in the fUML Execution Model, by the way, in which there may be multiple EnumerationLiteralValues that point to the same M1 EnumerationLiteral, but any two EnumerationLiteralValues for the same EnumerationLiteral are considered to be equal.) -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, April 11, 2013 12:28 PM To: Ed Willink; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Ed In UML, the phrases "EnumerationLiteral value" and "EnumerationLiteral object memory address" have no meaning. The phrase "An EnumerationLiteral" means "an instance of the metaclass EnumerationLiteral". So the wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" means "an instance of the metaclass EnumerationLiteral is equal to itself and not equal to anything other than itself". I don't see how this is vague. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 11 April 2013 17:14 To: uml25-ftf@omg.org Subject: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Hi The new wording "an EnumerationLiteral is equal to itself and not equal to anything other than itself" is vague Is "itself" the EnumerationLiteral value or the EnumerationLiteral object memory address? Since an EnumerationLiteral is a DataType instance, perhaps the description can just delegate to datatype equality by deep value equivalence. Regards Ed Willink --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: "Bock, Conrad" To: "Manfred R. Koethe" , "uml25-ftf@omg.org" Date: Tue, 23 Apr 2013 11:02:11 -0400 Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/TPJl/HHm5oEmAls4KFmW8kZjRqueAgAAEWgCAAAkJAIAAF8+AgAEM8QCAAIBFgIABW/QAgArr3gCABI9CAP//weFAgAABXjA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Nicolas, > However, as long as the example I gave is supported; I'm cool. It might, given Steve's explanation, but it's not completely clear. My understanding is you want two unequal runtime integers that also conform to the same enumeration literal (due to generalization in the model) will be treated as equal, and the semantics of TestIdentityAction says: For a PrimitiveType, equality of value is determined by the definition of the type, outside of UML. For an Enumeration, an EnumerationLiteral is equal to another value if it is the same EnumerationLiteral. Otherwise, an instance of a DataType is equal to another value if it is a direct instance of the same DataType with identical values for corresponding attributes (with "identical values" determined recursively as in a Test Identity Action). In your example, the rutime value is both a PrimitiveType and EnumerationLiteral, I think, and there's cross talk between conforming to an instance spec and being classified by an Enumeration, so the language is little tricky. Conrad From: Steve Cook To: "Rouquette, Nicolas F (313K)" , "Bock, Conrad" , "Manfred R. Koethe" , "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/mYUDCX6Lw3EiryquvTAL6/pjRNFCggAAFmACAAAkJAIAAF8+AgAEGogCAAIaUgIABWTKQgAtj/ACABBZvEIAAO3qAgAACY4CAAGxfAIAAw82Q Date: Wed, 24 Apr 2013 09:19:53 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(199002)(189002)(13464002)(5403001)(377454001)(50466001)(47736001)(49866001)(76482001)(81542001)(59766001)(77982001)(50986001)(20776003)(53806001)(54356001)(33656001)(54316002)(56776001)(31966008)(4396001)(16406001)(63696002)(6806003)(47446002)(74502001)(74662001)(79102001)(81342001)(69226001)(80022001)(65816001)(55846006)(23726002)(47776003)(46102001)(56816002)(46406003)(47976001)(51856001)(44976003);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB020;H:TK5EX14HUBC104.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0826B2F01B X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r3O9KP06015060 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Well, I hope that we are agreed that this particular problem of equality can be separated from 8274 (which was about Enumerations having attributes), and if it is an issue at all then that issue is a separate one, perhaps related to the wording of TestIdentityAction. -- Steve -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 23 April 2013 22:30 To: Bock, Conrad; Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Conrad, I agree the situation needs clarification: 1) An EnumerationLiteral is an InstanceSpecification (it is not a ValueSpecification); it is a specification that 0 or more "individuals" in the interpretation of the model 2) A ValueSpecification is a specification of 0 or more "values" in the interpretation of the model 3) UML assumes that the interpretation of a model makes a non-overlapping distinction between between "individuals" and "values" 4) In the interpretation of a model, a "value" could correspond to a single thing (e.g. a number) or a single range of things (e.g., an interval) - Nicolas. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Tuesday, April 23, 2013 8:02 AM To: Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Nicolas, > However, as long as the example I gave is supported; I'm cool. It might, given Steve's explanation, but it's not completely clear. My understanding is you want two unequal runtime integers that also conform to the same enumeration literal (due to generalization in the model) will be treated as equal, and the semantics of TestIdentityAction says: For a PrimitiveType, equality of value is determined by the definition of the type, outside of UML. For an Enumeration, an EnumerationLiteral is equal to another value if it is the same EnumerationLiteral. Otherwise, an instance of a DataType is equal to another value if it is a direct instance of the same DataType with identical values for corresponding attributes (with "identical values" determined recursively as in a Test Identity Action). In your example, the rutime value is both a PrimitiveType and EnumerationLiteral, I think, and there's cross talk between conforming to an instance spec and being classified by an Enumeration, so the language is little tricky. Conrad From: "Rouquette, Nicolas F (313K)" To: "Bock, Conrad" , "Manfred R. Koethe" , "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/TPJl/HHm5oEmAls4KFmW8kZjRqueAgAAEWgCAAAkJAIAAF8+AgAEM8QCAAIBFgIABW/QAgArr3gCABI9CAP//weFAgAABXjCAAFkvYA== Date: Tue, 23 Apr 2013 21:30:04 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.27] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r3NLUp6r030752 X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== Conrad, I agree the situation needs clarification: 1) An EnumerationLiteral is an InstanceSpecification (it is not a ValueSpecification); it is a specification that 0 or more "individuals" in the interpretation of the model 2) A ValueSpecification is a specification of 0 or more "values" in the interpretation of the model 3) UML assumes that the interpretation of a model makes a non-overlapping distinction between between "individuals" and "values" 4) In the interpretation of a model, a "value" could correspond to a single thing (e.g. a number) or a single range of things (e.g., an interval) - Nicolas. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Tuesday, April 23, 2013 8:02 AM To: Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Nicolas, > However, as long as the example I gave is supported; I'm cool. It might, given Steve's explanation, but it's not completely clear. My understanding is you want two unequal runtime integers that also conform to the same enumeration literal (due to generalization in the model) will be treated as equal, and the semantics of TestIdentityAction says: For a PrimitiveType, equality of value is determined by the definition of the type, outside of UML. For an Enumeration, an EnumerationLiteral is equal to another value if it is the same EnumerationLiteral. Otherwise, an instance of a DataType is equal to another value if it is a direct instance of the same DataType with identical values for corresponding attributes (with "identical values" determined recursively as in a Test Identity Action). In your example, the rutime value is both a PrimitiveType and EnumerationLiteral, I think, and there's cross talk between conforming to an instance spec and being classified by an Enumeration, so the language is little tricky. Conrad From: "Rouquette, Nicolas F (313K)" To: "Bock, Conrad" , "Manfred R. Koethe" , "uml25-ftf@omg.org" Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Topic: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Thread-Index: AQHONs/TPJl/HHm5oEmAls4KFmW8kZjRqueAgAAEWgCAAAkJAIAAF8+AgAEM8QCAAIBFgIABW/QAgArr3gCABI9CAP//weFAgAABXjCAAFkvYA== Date: Tue, 23 Apr 2013 21:30:04 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.27] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r3NLUp6r030752 X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== Conrad, I agree the situation needs clarification: 1) An EnumerationLiteral is an InstanceSpecification (it is not a ValueSpecification); it is a specification that 0 or more "individuals" in the interpretation of the model 2) A ValueSpecification is a specification of 0 or more "values" in the interpretation of the model 3) UML assumes that the interpretation of a model makes a non-overlapping distinction between between "individuals" and "values" 4) In the interpretation of a model, a "value" could correspond to a single thing (e.g. a number) or a single range of things (e.g., an interval) - Nicolas. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Tuesday, April 23, 2013 8:02 AM To: Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: Ballot 4: Issue 8274 : UML2/Infra section 11.6.2/ Enumerations should not have attributes Nicolas, > However, as long as the example I gave is supported; I'm cool. It might, given Steve's explanation, but it's not completely clear. My understanding is you want two unequal runtime integers that also conform to the same enumeration literal (due to generalization in the model) will be treated as equal, and the semantics of TestIdentityAction says: For a PrimitiveType, equality of value is determined by the definition of the type, outside of UML. For an Enumeration, an EnumerationLiteral is equal to another value if it is the same EnumerationLiteral. Otherwise, an instance of a DataType is equal to another value if it is a direct instance of the same DataType with identical values for corresponding attributes (with "identical values" determined recursively as in a Test Identity Action). In your example, the rutime value is both a PrimitiveType and EnumerationLiteral, I think, and there's cross talk between conforming to an instance spec and being classified by an Enumeration, so the language is little tricky. Conrad