Issue 15107: Enumeration Literal (uml2-rtf) Source: International Business Machines (Dr. Maged Elaasar, melaasar(at)ca.ibm.com) Nature: Uncategorized Issue Severity: Summary: EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense. is it another case of unintended inheritance? Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement? Resolution: Revised Text: Actions taken: January 15, 2010: received issu8e Discussion: End of Annotations:===== ubject: Enumeration Literal To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 15 Jan 2010 14:00:34 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 01/15/2010 14:00:41 Hello All, EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense. is it another case of unintended inheritance? Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: Enumeration Literal Date: Fri, 15 Jan 2010 12:19:23 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enumeration Literal Thread-Index: AcqWFSrSH4myprGfQumAvv5FQ+UobQABIQTg From: "Pete Rivett" To: "Maged Elaasar" , Note that EnumerationLiteral::enumeration subsets NamedElement::namespace not PackageableElement::owningPackage (which itself also subsets NamedElement::namespace which is a derived union . which affects the interpretation of .subsets.). So I guess that means that a given EnumerationLiteral is either owned by an Enumeration or a Package (but not both of course). If owned by a Package then it could not even be connected to an Enumeration via the enumeration property (since that would imply dual ownership). An EnumerationLiteral without an Enumeration seems nonsense, hence treating it as a PackageableElement is also nonsense as you imply.. This is another example of where trying to do things at the property level (instead of simple patterns of association generalization) leaves us in confusion where even the experts are not clear what the specification means! Regardless of the above, I do not think EnumerationLiterals should be InstanceSpecifications at all! So even the .intended. inheritance is wrong! See Issue 8278 (which I raised in Feb 2005 complete with proposed resolution!). Adopting that proposal avoids the specific problem of EnumerationLiteral (but not the general one of a comprehensible specification). Also Issue 8274 is relevant. With regard to names being coupled to visibility, imports are also tied to naming (the only impact of an import is to make names usable without qualification). People often assume imports have more standing (e.g. that one should Import a Profile/package when referencing elements from it) and that might make sense . but it.s not what the specification says. This all reflects a programming language (where names matter) rather than a modeling mentality which does not reflect a lot of UML usage. [Aside: MOF explicitly ignores visibility and treats everything as public. It would be clearer if the UML metamodel reflected this and had all elements as public . looking at it recently I saw many were private] Regards Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 15 January 2010 11:01 To: uml2-rtf@omg.org Subject: Enumeration Literal Hello All, EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense. is it another case of unintended inheritance? Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: Enumeration Literal To: "Pete Rivett" Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 15 Jan 2010 15:35:41 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 01/15/2010 15:35:42 Pete, I like the solution offered in 8278, i.e. making Enum Literal inherit from NamedElement with an optional 'value' attribute, but is it something we entertain in this RTF? If yes, that would be my choice too. However, I was going to propose making enum literal redefine 'classifier' to : /classifier:Enumeration [1] with a derivation classifier = enumeration. What do you think? "Pete Rivett" "Pete Rivett" 01/15/2010 03:19 PM To Maged Elaasar/Ottawa/IBM@IBMCA, cc Subject RE: Enumeration Literal Note that EnumerationLiteral::enumeration subsets NamedElement::namespace not PackageableElement::owningPackage (which itself also subsets NamedElement::namespace which is a derived union . which affects the interpretation of .subsets.). So I guess that means that a given EnumerationLiteral is either owned by an Enumeration or a Package (but not both of course). If owned by a Package then it could not even be connected to an Enumeration via the enumeration property (since that would imply dual ownership). An EnumerationLiteral without an Enumeration seems nonsense, hence treating it as a PackageableElement is also nonsense as you imply.. This is another example of where trying to do things at the property level (instead of simple patterns of association generalization) leaves us in confusion where even the experts are not clear what the specification means! Regardless of the above, I do not think EnumerationLiterals should be InstanceSpecifications at all! So even the .intended. inheritance is wrong! See Issue 8278 (which I raised in Feb 2005 complete with proposed resolution!). Adopting that proposal avoids the specific problem of EnumerationLiteral (but not the general one of a comprehensible specification). Also Issue 8274 is relevant. With regard to names being coupled to visibility, imports are also tied to naming (the only impact of an import is to make names usable without qualification). People often assume imports have more standing (e.g. that one should Import a Profile/package when referencing elements from it) and that might make sense . but it.s not what the specification says. This all reflects a programming language (where names matter) rather than a modeling mentality which does not reflect a lot of UML usage. [Aside: MOF explicitly ignores visibility and treats everything as public. It would be clearer if the UML metamodel reflected this and had all elements as public . looking at it recently I saw many were private] Regards Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 15 January 2010 11:01 To: uml2-rtf@omg.org Subject: Enumeration Literal Hello All, EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense. is it another case of unintended inheritance? Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic08951.gif Subject: RE: Enumeration Literal To: Maged Elaasar Cc: "Pete Rivett" , uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 15 Jan 2010 15:37:31 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 01/15/2010 15:37:32 Although.,,,,with the resolution in 8278, enum literal would not be a value spec, how would it still be assignable as a value to properties typed with the enumeration? Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 01/15/2010 03:35 PM To "Pete Rivett" cc uml2-rtf@omg.org Subject RE: Enumeration Literal Pete, I like the solution offered in 8278, i.e. making Enum Literal inherit from NamedElement with an optional 'value' attribute, but is it something we entertain in this RTF? If yes, that would be my choice too. However, I was going to propose making enum literal redefine 'classifier' to : /classifier:Enumeration [1] with a derivation classifier = enumeration. What do you think? "Pete Rivett" "Pete Rivett" 01/15/2010 03:19 PM To Maged Elaasar/Ottawa/IBM@IBMCA, cc Subject RE: Enumeration Literal Note that EnumerationLiteral::enumeration subsets NamedElement::namespace not PackageableElement::owningPackage (which itself also subsets NamedElement::namespace which is a derived union . which affects the interpretation of .subsets.). So I guess that means that a given EnumerationLiteral is either owned by an Enumeration or a Package (but not both of course). If owned by a Package then it could not even be connected to an Enumeration via the enumeration property (since that would imply dual ownership). An EnumerationLiteral without an Enumeration seems nonsense, hence treating it as a PackageableElement is also nonsense as you imply.. This is another example of where trying to do things at the property level (instead of simple patterns of association generalization) leaves us in confusion where even the experts are not clear what the specification means! Regardless of the above, I do not think EnumerationLiterals should be InstanceSpecifications at all! So even the .intended. inheritance is wrong! See Issue 8278 (which I raised in Feb 2005 complete with proposed resolution!). Adopting that proposal avoids the specific problem of EnumerationLiteral (but not the general one of a comprehensible specification). Also Issue 8274 is relevant. With regard to names being coupled to visibility, imports are also tied to naming (the only impact of an import is to make names usable without qualification). People often assume imports have more standing (e.g. that one should Import a Profile/package when referencing elements from it) and that might make sense . but it.s not what the specification says. This all reflects a programming language (where names matter) rather than a modeling mentality which does not reflect a lot of UML usage. [Aside: MOF explicitly ignores visibility and treats everything as public. It would be clearer if the UML metamodel reflected this and had all elements as public . looking at it recently I saw many were private] Regards Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 15 January 2010 11:01 To: uml2-rtf@omg.org Subject: Enumeration Literal Hello All, EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense. is it another case of unintended inheritance? Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic15407.gif pic29860.gif Subject: RE: Enumeration Literal Date: Fri, 15 Jan 2010 16:18:55 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Enumeration Literal thread-index: AcqWIwBjYYZMbqqQRtCYHwDHPLPWmQAAqL2A From: "Ed Seidewitz" To: "Maged Elaasar" Cc: "Pete Rivett - Adaptive" , I also don.t particularly like EnumerationLiteral being a subclass of InstanceSpecification. However, I think changing this would be out of scope for this RTF. There are just too many issues that would have to be carefully considered, like the one Maged mentions below. Indeed, I think this is just the kind of issue that is the most dangerous for this RTF: something that seems like a good thing to do, but becomes more and more complicated to do right the more carefully you look at it. Whether or not you actual redefine classifier to a derived attribute, requiring the constraint .classifier = enumeration. seems to be a reasonable workaround for now. If, in addition, we make EnumerationLiteral::enumeration mandatory (I have no idea why it is 0..1 now), then an enumeration literal could not be owned by anything other than an enumeration, even if it is technically a packageable element. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, January 15, 2010 3:38 PM To: Maged Elaasar Cc: Pete Rivett - Adaptive; uml2-rtf@omg.org Subject: RE: Enumeration Literal Although.,,,,with the resolution in 8278, enum literal would not be a value spec, how would it still be assignable as a value to properties typed with the enumeration? Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 01/15/2010 03:35 PM To "Pete Rivett" cc uml2-rtf@omg.org Subject RE: Enumeration Literal Pete, I like the solution offered in 8278, i.e. making Enum Literal inherit from NamedElement with an optional 'value' attribute, but is it something we entertain in this RTF? If yes, that would be my choice too. However, I was going to propose making enum literal redefine 'classifier' to : /classifier:Enumeration [1] with a derivation classifier = enumeration. What do you think? "Pete Rivett" "Pete Rivett" 01/15/2010 03:19 PM To Maged Elaasar/Ottawa/IBM@IBMCA, cc Subject RE: Enumeration Literal Note that EnumerationLiteral::enumeration subsets NamedElement::namespace not PackageableElement::owningPackage (which itself also subsets NamedElement::namespace which is a derived union . which affects the interpretation of .subsets.). So I guess that means that a given EnumerationLiteral is either owned by an Enumeration or a Package (but not both of course). If owned by a Package then it could not even be connected to an Enumeration via the enumeration property (since that would imply dual ownership). An EnumerationLiteral without an Enumeration seems nonsense, hence treating it as a PackageableElement is also nonsense as you imply.. This is another example of where trying to do things at the property level (instead of simple patterns of association generalization) leaves us in confusion where even the experts are not clear what the specification means! Regardless of the above, I do not think EnumerationLiterals should be InstanceSpecifications at all! So even the .intended. inheritance is wrong! See Issue 8278 (which I raised in Feb 2005 complete with proposed resolution!). Adopting that proposal avoids the specific problem of EnumerationLiteral (but not the general one of a comprehensible specification). Also Issue 8274 is relevant. With regard to names being coupled to visibility, imports are also tied to naming (the only impact of an import is to make names usable without qualification). People often assume imports have more standing (e.g. that one should Import a Profile/package when referencing elements from it) and that might make sense . but it.s not what the specification says. This all reflects a programming language (where names matter) rather than a modeling mentality which does not reflect a lot of UML usage. [Aside: MOF explicitly ignores visibility and treats everything as public. It would be clearer if the UML metamodel reflected this and had all elements as public . looking at it recently I saw many were private] Regards Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 15 January 2010 11:01 To: uml2-rtf@omg.org Subject: Enumeration Literal Hello All, EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense. is it another case of unintended inheritance? Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: Enumeration Literal Date: Fri, 15 Jan 2010 14:57:02 -0800 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Enumeration Literal Thread-Index: AcqWIqz2QOYQVwJjQYuXzqHTfq1EmAADWrRA From: "Pete Rivett" To: "Maged Elaasar" Cc: As things currently stand EnumerationLiteral is not a ValueSpecification either . to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. The spec also leaves open the question of whether different uses of the same EnumerationLiteral value would have different elements or not. Let.s say we have the definition of Color including the literal Red. And we have 2 attributes defined of type Color with default of Red. Do we then have 1, 2 or 3 instances of the EnumerationLiteral named Red? The only circumstantial clue we have from the spec is the sentence in 7.3.17 .The run-time values corresponding to enumeration literals can be compared for equality.. Which sort-of implies to me that the expectation is multiple values for Red (why else would it make sense to try to compare their values?) i.e.3 instances (one for the Enumeration definition, the others for the 2 default values). This would align with other elements such as LiteralInteger where one would expect multiple instances for the value 5. However you make a good point, Maged, with respect to the proposed solution in 8278 (): EnumerationLiteral should inherit from LiteralSpecification rather than directly from NamedElement. This is also intuitively what one would expect: just read the sections for InstanceSpecification and LiteralSpecification to see which is more appropriate for EnumerationLiteral. Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 15 January 2010 12:38 To: Maged Elaasar Cc: Pete Rivett; uml2-rtf@omg.org Subject: RE: Enumeration Literal Although.,,,,with the resolution in 8278, enum literal would not be a value spec, how would it still be assignable as a value to properties typed with the enumeration? Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 01/15/2010 03:35 PM To "Pete Rivett" cc uml2-rtf@omg.org Subject RE: Enumeration Literal Pete, I like the solution offered in 8278, i.e. making Enum Literal inherit from NamedElement with an optional 'value' attribute, but is it something we entertain in this RTF? If yes, that would be my choice too. However, I was going to propose making enum literal redefine 'classifier' to : /classifier:Enumeration [1] with a derivation classifier = enumeration. What do you think? "Pete Rivett" "Pete Rivett" 01/15/2010 03:19 PM To Maged Elaasar/Ottawa/IBM@IBMCA, cc Subject RE: Enumeration Literal Note that EnumerationLiteral::enumeration subsets NamedElement::namespace not PackageableElement::owningPackage (which itself also subsets NamedElement::namespace which is a derived union . which affects the interpretation of .subsets.). So I guess that means that a given EnumerationLiteral is either owned by an Enumeration or a Package (but not both of course). If owned by a Package then it could not even be connected to an Enumeration via the enumeration property (since that would imply dual ownership). An EnumerationLiteral without an Enumeration seems nonsense, hence treating it as a PackageableElement is also nonsense as you imply.. This is another example of where trying to do things at the property level (instead of simple patterns of association generalization) leaves us in confusion where even the experts are not clear what the specification means! Regardless of the above, I do not think EnumerationLiterals should be InstanceSpecifications at all! So even the .intended. inheritance is wrong! See Issue 8278 (which I raised in Feb 2005 complete with proposed resolution!). Adopting that proposal avoids the specific problem of EnumerationLiteral (but not the general one of a comprehensible specification). Also Issue 8274 is relevant. With regard to names being coupled to visibility, imports are also tied to naming (the only impact of an import is to make names usable without qualification). People often assume imports have more standing (e.g. that one should Import a Profile/package when referencing elements from it) and that might make sense . but it.s not what the specification says. This all reflects a programming language (where names matter) rather than a modeling mentality which does not reflect a lot of UML usage. [Aside: MOF explicitly ignores visibility and treats everything as public. It would be clearer if the UML metamodel reflected this and had all elements as public . looking at it recently I saw many were private] Regards Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 15 January 2010 11:01 To: uml2-rtf@omg.org Subject: Enumeration Literal Hello All, EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense. is it another case of unintended inheritance? Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: Enumeration Literal Date: Fri, 15 Jan 2010 19:21:07 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enumeration Literal thread-index: AcqWIqz2QOYQVwJjQYuXzqHTfq1EmAADWrRAAARD/dA= From: "Ed Seidewitz" To: "Pete Rivett - Adaptive" , "Maged Elaasar" Cc: Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 5:57 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either . to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. [EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value. Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area . but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4. The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.) -- Ed Subject: RE: Enumeration Literal Date: Fri, 15 Jan 2010 17:11:47 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enumeration Literal Thread-Index: AcqWIqz2QOYQVwJjQYuXzqHTfq1EmAADWrRAAARD/dAAAcR7AA== From: "Pete Rivett" To: "Ed Seidewitz" , "Maged Elaasar" Cc: Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and not one vendor got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 15 January 2010 16:21 To: Pete Rivett; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 5:57 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either . to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. [EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value. Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area . but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4. The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.) -- Ed Subject: RE: Enumeration Literal Date: Sat, 16 Jan 2010 12:29:29 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enumeration Literal thread-index: AcqWIqz2QOYQVwJjQYuXzqHTfq1EmAADWrRAAARD/dAAAcR7AAAiJaEA From: "Cory Casanave" To: "Pete Rivett - Adaptive" , "Ed Seidewitz" , "Maged Elaasar" Cc: It has always confounded me why we have of all the complexity of .instance specification. and .Enumeration Literals. instead of the simple and well defined concept of a regular instance. In that way an enumeration is just a class with a closed and enumerated extent of plain old instances. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 8:12 PM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and not one vendor got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 15 January 2010 16:21 To: Pete Rivett; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 5:57 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either . to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. [EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value. Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area . but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4. The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.) -- Ed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=Ex4vRTrkWiJZ74fv0ABlrbY53AjzoY9tZGkH13k8qfY=; b=j3A0Za01lGl5YyxTwP4BMNpgGB7682WmzQhEZzNgYBNeQ3+/TJYnEYsJRNap8px6Mx K8s+ggarStMOgn3MT+VEYX18WfyhlLdOEQrym8phVg7CIJ1qtCfxqXIfjS+N6wdAvcff 2OCmC3FCpEYIy0vAhi3a8oBkPrar3TE8Dm+/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=G4ZIqFv+rg/M0zo6NE1ZCEoWcDmpRGCsDWunDXw/lwuEGRt5rVKyKZ0iOgNY+kP5KS 9c3eARagtQlm5TMW5ZofyXbQq5wJtHaB+mv1+/p+SgnaXxdAK5sMVcEESDp4ZKHTHds9 vT54ddnfu6v/R1zwUS2w/ZDUe9ysH16KL9G/M= Sender: bran.selic@gmail.com From: Bran Selic Date: Sun, 17 Jan 2010 14:48:48 -0500 X-Google-Sender-Auth: aef25527caf4b5e4 Subject: Re: Enumeration Literal To: Cory Casanave Cc: Pete Rivett - Adaptive , Ed Seidewitz , Maged Elaasar , uml2-rtf@omg.org Cory, This goes back to an almost ancient discussion about the difference between objects, which have identity, and values, which do not. Enumeration literals shoud be values, not object instances. Cheers...Bran On Sat, Jan 16, 2010 at 12:29 PM, Cory Casanave wrote: It has always confounded me why we have of all the complexity of .instance specification. and .Enumeration Literals. instead of the simple and well defined concept of a regular instance. In that way an enumeration is just a class with a closed and enumerated extent of plain old instances. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 8:12 PM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and not one vendor got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 15 January 2010 16:21 To: Pete Rivett; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 5:57 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either . to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. [EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value. Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area . but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4. The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.) -- Ed Date: Sun, 17 Jan 2010 15:24:52 -0500 From: Andre Cusson Organization: 01 COMMUNICATIONS INC. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Bran Selic Cc: Cory Casanave , Pete Rivett - Adaptive , Ed Seidewitz , Maged Elaasar , uml2-rtf@omg.org Subject: Re: Enumeration Literal Hi, Assuming a value may not have an identity, shouldn't the enumeration, a value holding structure/concept/resource have one? Is a value list a value and if so, is a value record (e.g. record instance) a value also? if so, then anything can be a value and values can also be identified (and objects can also be unidentified!). Doesn't it seem like only atomic values could "not have identity", not precluding the fact that they may still have identity (e.g. variable, parameter, attribute, property). I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts. Maybe the Object-Oriented view that objects have identity and values do not, is a little "ancient", as you say. Cheers, Andre Cory, This goes back to an almost ancient discussion about the difference between objects, which have identity, and values, which do not. Enumeration literals shoud be values, not object instances. Cheers...Bran On Sat, Jan 16, 2010 at 12:29 PM, Cory Casanave > wrote: It has always confounded me why we have of all the complexity of .instance specification. and .Enumeration Literals. instead of the simple and well defined concept of a regular instance. In that way an enumeration is just a class with a closed and enumerated extent of plain old instances. -Cory ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 8:12 PM *To:* Ed Seidewitz; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and _not one vendor_ got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com ] *Sent:* 15 January 2010 16:21 *To:* Pete Rivett; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Pete -- ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 5:57 PM *To:* Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either ­ to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. */[EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value./* */ /* */Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area ­ but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4./* */ /* */The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.)/* */ /* */-- Ed/* X-Auth-ID: koethe Subject: Re: Enumeration Literal From: "Manfred R. Koethe" Date: Sun, 17 Jan 2010 19:48:19 -0500 Cc: Bran Selic , Cory Casanave , Pete Rivett - Adaptive , Ed Seidewitz , Maged Elaasar , uml2-rtf@omg.org To: Andre Cusson X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1077) X-Junkmail-Status: score=10/50, host=mr08.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A020204.4B53AFE0.0027,ss=1,fgs=0, ip=207.172.4.11, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Hi Andre, I think you answered your question with your second last sentence: "I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts." A value does not have a separate identity, it is self-idientifying. And in that respect are enumeration literals like "RED" or "BLUE" conceptually equivalent to, for example, numeral literals like "2" or "5". Giving a value an identity separate form the value it represents would for example make the equivalence operator highly ambiguous, if not incorrect. Kind regards, Manfred On Jan 17, 2010, at 15:24 , Andre Cusson wrote: Hi, Assuming a value may not have an identity, shouldn't the enumeration, a value holding structure/concept/resource have one? Is a value list a value and if so, is a value record (e.g. record instance) a value also? if so, then anything can be a value and values can also be identified (and objects can also be unidentified!). Doesn't it seem like only atomic values could "not have identity", not precluding the fact that they may still have identity (e.g. variable, parameter, attribute, property). I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts. Maybe the Object-Oriented view that objects have identity and values do not, is a little "ancient", as you say. Cheers, Andre Cory, This goes back to an almost ancient discussion about the difference between objects, which have identity, and values, which do not. Enumeration literals shoud be values, not object instances. Cheers...Bran On Sat, Jan 16, 2010 at 12:29 PM, Cory Casanave > wrote: It has always confounded me why we have of all the complexity of .instance specification. and .Enumeration Literals. instead of the simple and well defined concept of a regular instance. In that way an enumeration is just a class with a closed and enumerated extent of plain old instances. -Cory ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 8:12 PM *To:* Ed Seidewitz; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and _not one vendor_ got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com ] *Sent:* 15 January 2010 16:21 *To:* Pete Rivett; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Pete -- ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 5:57 PM *To:* Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either . to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. */[EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value./* */ /* */Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area . but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4./* */ /* */The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.)/* */ /* */-- Ed/* --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (617) 848 8819 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- PGP17.sig Date: Sun, 17 Jan 2010 23:00:36 -0500 From: Andre Cusson Organization: 01 COMMUNICATIONS INC. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "Manfred R. Koethe" Cc: Bran Selic , Cory Casanave , Pete Rivett - Adaptive , Ed Seidewitz , Maged Elaasar , uml2-rtf@omg.org Subject: Re: Enumeration Literal Hi Manfred, Agreed. Enumeration values are typically atomic values and we often use them without further identification, especially as by definition their value identifies them. Values can still be additionally identified and often are, for example, when I write let a=5, I am identifying the value 5 as a, and I can now refer to it as a, without any "object" involved. An enumeration is a structure but similarly, that structure could be literal (e.g. self-identified) and/or additionally identified. The same thing is true for records and of "objects". In fact, additional identification, other than self-identification (e.g. literal value) is required for management (in case there is more than 1, which is typically (always) the case), not because it is a value or an object. In other words, the "difference between objects, which have identity, and values, which do not" seems ill founded and confusing, not to mention "ancient" or outdated. Nothing is so unique that it cannot be put in a group of some kind, even the cosmos which is supposed to encompass everything and every concept, and certainly not God if we judge by how many we have and support. Consequently, all these (and other) "resources" are all (multiply) identified. In other words, identification is a fundamental logic requirement, not an object distinguishing property. Cheers, Andre Hi Andre, I think you answered your question with your second last sentence: "I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts." A value does not have a separate identity, it is self-idientifying. And in that respect are enumeration literals like "RED" or "BLUE" conceptually equivalent to, for example, numeral literals like "2" or "5". Giving a value an identity separate form the value it represents would for example make the equivalence operator highly ambiguous, if not incorrect. Kind regards, Manfred On Jan 17, 2010, at 15:24 , Andre Cusson wrote: Hi, Assuming a value may not have an identity, shouldn't the enumeration, a value holding structure/concept/resource have one? Is a value list a value and if so, is a value record (e.g. record instance) a value also? if so, then anything can be a value and values can also be identified (and objects can also be unidentified!). Doesn't it seem like only atomic values could "not have identity", not precluding the fact that they may still have identity (e.g. variable, parameter, attribute, property). I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts. Maybe the Object-Oriented view that objects have identity and values do not, is a little "ancient", as you say. Cheers, Andre Cory, This goes back to an almost ancient discussion about the difference between objects, which have identity, and values, which do not. Enumeration literals shoud be values, not object instances. Cheers...Bran On Sat, Jan 16, 2010 at 12:29 PM, Cory Casanave > wrote: It has always confounded me why we have of all the complexity of .instance specification. and .Enumeration Literals. instead of the simple and well defined concept of a regular instance. In that way an enumeration is just a class with a closed and enumerated extent of plain old instances. -Cory ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 8:12 PM *To:* Ed Seidewitz; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and _not one vendor_ got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com ] *Sent:* 15 January 2010 16:21 *To:* Pete Rivett; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Pete -- ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 5:57 PM *To:* Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either ­ to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. */[EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value./* */ /* */Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area ­ but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4./* */ /* */The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.)/* */ /* */-- Ed/* --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (617) 848 8819 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- X-Auth-ID: koethe Subject: Re: Enumeration Literal From: "Manfred R. Koethe" Date: Mon, 18 Jan 2010 00:38:29 -0500 Cc: Bran Selic , Cory Casanave , Pete Rivett - Adaptive , Ed Seidewitz , Maged Elaasar , uml2-rtf@omg.org To: Andre Cusson X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1077) X-Junkmail-Status: score=10/50, host=mr08.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A020205.4B53F406.0138,ss=1,fgs=0, ip=207.172.4.11, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Hi Andre, I respectfully disagree with you in several points. 1. Enumerations are not structures. In common understanding and all type systems I came across are enumerations defined as primitive types with a closed, and predefined set of discrete type values, constituting the complete extent of the enumeration type. Enumeration literals have therefore no own identity besides their value. 2. If you say a=5, you are not giving "5" the identity "a", instead, depending of what "a" represents, you make "a" holding a value "5", or eventually making, "a" a proxy for the numeral literal "5". But in both cases you do not change the identity of "5", which continues to be exclusively identified by its value "5". 3. I believe the distinction between values and objects is fundamental and very important. If you would consider "5" as an entity with distinct identity and value, than you would allow a situation where that thing with identity "5" could hold a value different from 5. This would break any form of arithmetic expression, for example: You couldn't say that 5 == 5 is arithmetic true, since you would compare only identities. With values in the common understanding, you could. I think the distinction between values (self-identified) and objects (with discrete identity) might be ancient, but is very important and in no way outdated. Kind regards, Manfred On Jan 17, 2010, at 23:00 , Andre Cusson wrote: Hi Manfred, Agreed. Enumeration values are typically atomic values and we often use them without further identification, especially as by definition their value identifies them. Values can still be additionally identified and often are, for example, when I write let a=5, I am identifying the value 5 as a, and I can now refer to it as a, without any "object" involved. An enumeration is a structure but similarly, that structure could be literal (e.g. self-identified) and/or additionally identified. The same thing is true for records and of "objects". In fact, additional identification, other than self-identification (e.g. literal value) is required for management (in case there is more than 1, which is typically (always) the case), not because it is a value or an object. In other words, the "difference between objects, which have identity, and values, which do not" seems ill founded and confusing, not to mention "ancient" or outdated. Nothing is so unique that it cannot be put in a group of some kind, even the cosmos which is supposed to encompass everything and every concept, and certainly not God if we judge by how many we have and support. Consequently, all these (and other) "resources" are all (multiply) identified. In other words, identification is a fundamental logic requirement, not an object distinguishing property. Cheers, Andre Hi Andre, I think you answered your question with your second last sentence: "I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts." A value does not have a separate identity, it is self-idientifying. And in that respect are enumeration literals like "RED" or "BLUE" conceptually equivalent to, for example, numeral literals like "2" or "5". Giving a value an identity separate form the value it represents would for example make the equivalence operator highly ambiguous, if not incorrect. Kind regards, Manfred On Jan 17, 2010, at 15:24 , Andre Cusson wrote: Hi, Assuming a value may not have an identity, shouldn't the enumeration, a value holding structure/concept/resource have one? Is a value list a value and if so, is a value record (e.g. record instance) a value also? if so, then anything can be a value and values can also be identified (and objects can also be unidentified!). Doesn't it seem like only atomic values could "not have identity", not precluding the fact that they may still have identity (e.g. variable, parameter, attribute, property). I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts. Maybe the Object-Oriented view that objects have identity and values do not, is a little "ancient", as you say. Cheers, Andre Cory, This goes back to an almost ancient discussion about the difference between objects, which have identity, and values, which do not. Enumeration literals shoud be values, not object instances. Cheers...Bran On Sat, Jan 16, 2010 at 12:29 PM, Cory Casanave > wrote: It has always confounded me why we have of all the complexity of .instance specification. and .Enumeration Literals. instead of the simple and well defined concept of a regular instance. In that way an enumeration is just a class with a closed and enumerated extent of plain old instances. -Cory ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 8:12 PM *To:* Ed Seidewitz; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and _not one vendor_ got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com ] *Sent:* 15 January 2010 16:21 *To:* Pete Rivett; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Pete -- ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 5:57 PM *To:* Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either . to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. */[EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value./* */ /* */Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area . but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4./* */ /* */The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.)/* */ /* */-- Ed/* --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (617) 848 8819 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (617) 848 8819 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- PGP18.sig Date: Mon, 18 Jan 2010 01:13:02 -0500 From: "Chonoles, Michael J" Subject: RE: Enumeration Literal To: "Manfred R. Koethe" , Andre Cusson Cc: Bran Selic , Cory Casanave , Pete Rivett - Adaptive , Ed Seidewitz , Maged Elaasar , "uml2-rtf@omg.org" Thread-Topic: Enumeration Literal Thread-Index: AcqYARrWVnpn6JbYR9efLtR7itVQegAA7wTQ Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: In fact, it was possible in some programming languages (such as FORTRAN) to set the literal .5. to have the internal value of 4, i.e., to effectively assign 4 to the constant .5.. As you can imagine, this led to horrendous debugging problems. Michael Jesse Chonoles LMCO From: Manfred R. Koethe [mailto:koethe@88solutions.com] Sent: Monday, January 18, 2010 12:38 AM To: Andre Cusson Cc: Bran Selic; Cory Casanave; Pete Rivett - Adaptive; Ed Seidewitz; Maged Elaasar; uml2-rtf@omg.org Subject: Re: Enumeration Literal Hi Andre, I respectfully disagree with you in several points. 1. Enumerations are not structures. In common understanding and all type systems I came across are enumerations defined as primitive types with a closed, and predefined set of discrete type values, constituting the complete extent of the enumeration type. Enumeration literals have therefore no own identity besides their value. 2. If you say a=5, you are not giving "5" the identity "a", instead, depending of what "a" represents, you make "a" holding a value "5", or eventually making, "a" a proxy for the numeral literal "5". But in both cases you do not change the identity of "5", which continues to be exclusively identified by its value "5". 3. I believe the distinction between values and objects is fundamental and very important. If you would consider "5" as an entity with distinct identity and value, than you would allow a situation where that thing with identity "5" could hold a value different from 5. This would break any form of arithmetic expression, for example: You couldn't say that 5 == 5 is arithmetic true, since you would compare only identities. With values in the common understanding, you could. I think the distinction between values (self-identified) and objects (with discrete identity) might be ancient, but is very important and in no way outdated. Kind regards, Manfred On Jan 17, 2010, at 23:00 , Andre Cusson wrote: Hi Manfred, Agreed. Enumeration values are typically atomic values and we often use them without further identification, especially as by definition their value identifies them. Values can still be additionally identified and often are, for example, when I write let a=5, I am identifying the value 5 as a, and I can now refer to it as a, without any "object" involved. An enumeration is a structure but similarly, that structure could be literal (e.g. self-identified) and/or additionally identified. The same thing is true for records and of "objects". In fact, additional identification, other than self-identification (e.g. literal value) is required for management (in case there is more than 1, which is typically (always) the case), not because it is a value or an object. In other words, the "difference between objects, which have identity, and values, which do not" seems ill founded and confusing, not to mention "ancient" or outdated. Nothing is so unique that it cannot be put in a group of some kind, even the cosmos which is supposed to encompass everything and every concept, and certainly not God if we judge by how many we have and support. Consequently, all these (and other) "resources" are all (multiply) identified. In other words, identification is a fundamental logic requirement, not an object distinguishing property. Cheers, Andre Hi Andre, I think you answered your question with your second last sentence: "I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts." A value does not have a separate identity, it is self-idientifying. And in that respect are enumeration literals like "RED" or "BLUE" conceptually equivalent to, for example, numeral literals like "2" or "5". Giving a value an identity separate form the value it represents would for example make the equivalence operator highly ambiguous, if not incorrect. Kind regards, Manfred On Jan 17, 2010, at 15:24 , Andre Cusson wrote: Hi, Assuming a value may not have an identity, shouldn't the enumeration, a value holding structure/concept/resource have one? Is a value list a value and if so, is a value record (e.g. record instance) a value also? if so, then anything can be a value and values can also be identified (and objects can also be unidentified!). Doesn't it seem like only atomic values could "not have identity", not precluding the fact that they may still have identity (e.g. variable, parameter, attribute, property). I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts. Maybe the Object-Oriented view that objects have identity and values do not, is a little "ancient", as you say. Cheers, Andre Cory, This goes back to an almost ancient discussion about the difference between objects, which have identity, and values, which do not. Enumeration literals shoud be values, not object instances. Cheers...Bran On Sat, Jan 16, 2010 at 12:29 PM, Cory Casanave > wrote: It has always confounded me why we have of all the complexity of .instance specification. and .Enumeration Literals. instead of the simple and well defined concept of a regular instance. In that way an enumeration is just a class with a closed and enumerated extent of plain old instances. -Cory ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 8:12 PM *To:* Ed Seidewitz; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and _not one vendor_ got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com ] *Sent:* 15 January 2010 16:21 *To:* Pete Rivett; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Pete -- ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 5:57 PM *To:* Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either . to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. */[EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value./* */ /* */Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area . but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4./* */ /* */The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.)/* */ /* */-- Ed/* --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (617) 848 8819 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (617) 848 8819 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- Date: Mon, 18 Jan 2010 03:17:00 -0500 From: Andre Cusson Organization: 01 COMMUNICATIONS INC. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "Manfred R. Koethe" Cc: Bran Selic , Cory Casanave , Pete Rivett - Adaptive , Ed Seidewitz , Maged Elaasar , uml2-rtf@omg.org Subject: Re: Enumeration Literal Hi Manfred, Please do not get me wrong, I am only saying that identification does not seem like a major differentiator between values and objects. As far as I understand, an enumeration is an ordered value sequence, which seems to be getting close to structure. More so, those values can be strings (e.g. "red", "green", "blue") which also happen to be objects (e.g. Java). We should probably be careful in using "identity" to mean "equality" and keep it to designate the object (e.g. goal) of identification, while "identifier" is an identification artifact or tool (or object) designed to contribute to identity. In any case "2" is a symbol that identifies the abstract value of two, just as "a", once I have declared that "a" is a label (e.g. identifier) to represent the abstract value of two (e.g. let a=2). Note that I have used the expression "let a=2" rather then "var a=2" as the second typically identifies as "a", the memory address where a representation (e.g. label, identifier) of the (abstract) value of two is stored, while the first simply declares that I want to use "a" as an identifier to represent the (abstract) value of two. This nuance may get lost sometimes in some object-oriented languages but typically remains very important in most functional programing languages. In all these and other cases, it seems that we are working mostly with identifiers. As well, doesn't "1+1" also identify the abstract value of two, as "3-1", "two", etc. I would also think that with let a=2, let b=2, and let c=1+1, that a==b is arithmetically true, just as 1+1==2, or 2==2, or a==c, or c==2, etc., as all these identifiers represent the same abstract value. It is interesting to note that 1 in an additive system identifies an incremental value while in a multiplicative system it identifies a non incremental value. In a primary number system, it identifies an undefined value as with it, primary numbers could not be defined as all integers are integer divisible by 1. Isn't array index 2 an identifier, just like the seat #2 in row "A"? It is also interesting to note that while my social insurance number is a literal numeric representing an abstract numerical (e.g positive integer) value, it is more typically used to identify me. Is a literal string value much different from a specific object instance? not in Java anyway. Aren't identifiers often string literals (e.g. object instances)? The main idea behind identification is that if you do not identify something (e.g. the abstraction of something, as we only know and manage information about things (I much prefer "resources", especially as I do not tend to see people and even concepts as "things")), you can not refer to it, which tends to make managing it a bit limited. Whether it is an abstract numerical value, a color, a medical record (patient abstraction), or a being abstraction, seems to change very little to the fact, use, and purpose of identification. If identification is a major differentiator between values and objects, it must be in a rather closed and constrained context. Identification is a very fundamental knowledge and knowledge management principle. Discussing and understanding it is crucial. I find your disagreeing constructive and useful. Thank you. Cheers, Andre Hi Andre, I respectfully disagree with you in several points. 1. Enumerations are not structures. In common understanding and all type systems I came across are enumerations defined as primitive types with a closed, and predefined set of discrete type values, constituting the complete extent of the enumeration type. Enumeration literals have therefore no own identity besides their value. 2. If you say a=5, you are not giving "5" the identity "a", instead, depending of what "a" represents, you make "a" holding a value "5", or eventually making, "a" a proxy for the numeral literal "5". But in both cases you do not change the identity of "5", which continues to be exclusively identified by its value "5". 3. I believe the distinction between values and objects is fundamental and very important. If you would consider "5" as an entity with distinct identity and value, than you would allow a situation where that thing with identity "5" could hold a value different from 5. This would break any form of arithmetic expression, for example: You couldn't say that 5 == 5 is arithmetic true, since you would compare only identities. With values in the common understanding, you could. I think the distinction between values (self-identified) and objects (with discrete identity) might be ancient, but is very important and in no way outdated. Kind regards, Manfred On Jan 17, 2010, at 23:00 , Andre Cusson wrote: Hi Manfred, Agreed. Enumeration values are typically atomic values and we often use them without further identification, especially as by definition their value identifies them. Values can still be additionally identified and often are, for example, when I write let a=5, I am identifying the value 5 as a, and I can now refer to it as a, without any "object" involved. An enumeration is a structure but similarly, that structure could be literal (e.g. self-identified) and/or additionally identified. The same thing is true for records and of "objects". In fact, additional identification, other than self-identification (e.g. literal value) is required for management (in case there is more than 1, which is typically (always) the case), not because it is a value or an object. In other words, the "difference between objects, which have identity, and values, which do not" seems ill founded and confusing, not to mention "ancient" or outdated. Nothing is so unique that it cannot be put in a group of some kind, even the cosmos which is supposed to encompass everything and every concept, and certainly not God if we judge by how many we have and support. Consequently, all these (and other) "resources" are all (multiply) identified. In other words, identification is a fundamental logic requirement, not an object distinguishing property. Cheers, Andre Hi Andre, I think you answered your question with your second last sentence: "I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts." A value does not have a separate identity, it is self-idientifying. And in that respect are enumeration literals like "RED" or "BLUE" conceptually equivalent to, for example, numeral literals like "2" or "5". Giving a value an identity separate form the value it represents would for example make the equivalence operator highly ambiguous, if not incorrect. Kind regards, Manfred On Jan 17, 2010, at 15:24 , Andre Cusson wrote: Hi, Assuming a value may not have an identity, shouldn't the enumeration, a value holding structure/concept/resource have one? Is a value list a value and if so, is a value record (e.g. record instance) a value also? if so, then anything can be a value and values can also be identified (and objects can also be unidentified!). Doesn't it seem like only atomic values could "not have identity", not precluding the fact that they may still have identity (e.g. variable, parameter, attribute, property). I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts. Maybe the Object-Oriented view that objects have identity and values do not, is a little "ancient", as you say. Cheers, Andre Cory, This goes back to an almost ancient discussion about the difference between objects, which have identity, and values, which do not. Enumeration literals shoud be values, not object instances. Cheers...Bran On Sat, Jan 16, 2010 at 12:29 PM, Cory Casanave > wrote: It has always confounded me why we have of all the complexity of .instance specification. and .Enumeration Literals. instead of the simple and well defined concept of a regular instance. In that way an enumeration is just a class with a closed and enumerated extent of plain old instances. -Cory ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 8:12 PM *To:* Ed Seidewitz; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and _not one vendor_ got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com ] *Sent:* 15 January 2010 16:21 *To:* Pete Rivett; Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal Pete -- ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Friday, January 15, 2010 5:57 PM *To:* Maged Elaasar *Cc:* uml2-rtf@omg.org *Subject:* RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either ­ to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. */[EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value./* */ /* */Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area ­ but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4./* */ /* */The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.)/* */ /* */-- Ed/* --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (617) 848 8819 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (617) 848 8819 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- From: Steve Cook To: Ed Seidewitz , Maged Elaasar , "issues@omg.org" CC: Pete Rivett - Adaptive , "uml2-rtf@omg.org" Subject: RE: Enumeration Literal Thread-Topic: Enumeration Literal Thread-Index: AQHKliKPtm0CYPyJ/kCt5pCbZZJf95GXJGqAgAP8c7A= Date: Mon, 18 Jan 2010 10:17:36 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: > Whether or not you actual redefine classifier to a derived attribute, requiring the constraint .classifier = enumeration. seems to be a reasonable workaround for now. If, in addition, we make EnumerationLiteral::enumeration mandatory (I have no idea why it is 0..1 now), then an enumeration literal could not be owned by anything other than an enumeration, even if it is technically a packageable element.. This seems like the kind of resolution we should make immediately. I.m copying to issues@omg.org . because we need a new issue bases on Maged.s original email .EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which in turn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense.. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 15 January 2010 21:19 To: Maged Elaasar Cc: Pete Rivett - Adaptive; uml2-rtf@omg.org Subject: RE: Enumeration Literal I also don.t particularly like EnumerationLiteral being a subclass of InstanceSpecification. However, I think changing this would be out of scope for this RTF. There are just too many issues that would have to be carefully considered, like the one Maged mentions below. Indeed, I think this is just the kind of issue that is the most dangerous for this RTF: something that seems like a good thing to do, but becomes more and more complicated to do right the more carefully you look at it. Whether or not you actual redefine classifier to a derived attribute, requiring the constraint .classifier = enumeration. seems to be a reasonable workaround for now. If, in addition, we make EnumerationLiteral::enumeration mandatory (I have no idea why it is 0..1 now), then an enumeration literal could not be owned by anything other than an enumeration, even if it is technically a packageable element. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, January 15, 2010 3:38 PM To: Maged Elaasar Cc: Pete Rivett - Adaptive; uml2-rtf@omg.org Subject: RE: Enumeration Literal Although.,,,,with the resolution in 8278, enum literal would not be a value spec, how would it still be assignable as a value to properties typed with the enumeration? Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 01/15/2010 03:35 PM To "Pete Rivett" cc uml2-rtf@omg.org Subject RE: Enumeration Literal Pete, I like the solution offered in 8278, i.e. making Enum Literal inherit from NamedElement with an optional 'value' attribute, but is it something we entertain in this RTF? If yes, that would be my choice too. However, I was going to propose making enum literal redefine 'classifier' to : /classifier:Enumeration [1] with a derivation classifier = enumeration. What do you think? "Pete Rivett" "Pete Rivett" 01/15/2010 03:19 PM To Maged Elaasar/Ottawa/IBM@IBMCA, cc Subject RE: Enumeration Literal Note that EnumerationLiteral::enumeration subsets NamedElement::namespace not PackageableElement::owningPackage (which itself also subsets NamedElement::namespace which is a derived union . which affects the interpretation of .subsets.). So I guess that means that a given EnumerationLiteral is either owned by an Enumeration or a Package (but not both of course). If owned by a Package then it could not even be connected to an Enumeration via the enumeration property (since that would imply dual ownership). An EnumerationLiteral without an Enumeration seems nonsense, hence treating it as a PackageableElement is also nonsense as you imply.. This is another example of where trying to do things at the property level (instead of simple patterns of association generalization) leaves us in confusion where even the experts are not clear what the specification means! Regardless of the above, I do not think EnumerationLiterals should be InstanceSpecifications at all! So even the .intended. inheritance is wrong! See Issue 8278 (which I raised in Feb 2005 complete with proposed resolution!). Adopting that proposal avoids the specific problem of EnumerationLiteral (but not the general one of a comprehensible specification). Also Issue 8274 is relevant. With regard to names being coupled to visibility, imports are also tied to naming (the only impact of an import is to make names usable without qualification). People often assume imports have more standing (e.g. that one should Import a Profile/package when referencing elements from it) and that might make sense . but it.s not what the specification says. This all reflects a programming language (where names matter) rather than a modeling mentality which does not reflect a lot of UML usage. [Aside: MOF explicitly ignores visibility and treats everything as public. It would be clearer if the UML metamodel reflected this and had all elements as public . looking at it recently I saw many were private] Regards Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 15 January 2010 11:01 To: uml2-rtf@omg.org Subject: Enumeration Literal Hello All, EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense. is it another case of unintended inheritance? Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 From: Steve Cook To: Ed Seidewitz , Maged Elaasar , "issues@omg.org" CC: Pete Rivett - Adaptive , "uml2-rtf@omg.org" Subject: RE: Enumeration Literal Thread-Topic: Enumeration Literal Thread-Index: AQHKliKPtm0CYPyJ/kCt5pCbZZJf95GXJGqAgAP8c7A= Date: Mon, 18 Jan 2010 10:17:36 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.18.100919 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_70_90 0.1, SUPERLONG_LINE 0.05, BODY_SIZE_10000_PLUS 0, GIF_GCT_NOTSORTED 0, GIF_VERSION89A 0, IMGSPAM_TABLE_1 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P1_5 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __EMBEDDED_IMG 0, __EXTRA_MPART_TYPE_1 0, __EXTRA_MPART_TYPE_N1 0, __FRAUD_CONTACT_NAME 0, __GIF_ATTACHED 0, __HAS_HTML 0, __HAS_MSGID 0, __HTML_FONT_BLUE 0, __HTML_MSWORD 0, __IMGSPAM_TABLE_1 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STYLE_RATWARE_2 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NS ' X-PerlMx-SIL: Medium X-OriginalArrivalTime: 18 Jan 2010 10:18:21.0914 (UTC) FILETIME=[8FEA8BA0:01CA9827] > Whether or not you actual redefine classifier to a derived attribute, requiring the constraint .classifier = enumeration. seems to be a reasonable workaround for now. If, in addition, we make EnumerationLiteral::enumeration mandatory (I have no idea why it is 0..1 now), then an enumeration literal could not be owned by anything other than an enumeration, even if it is technically a packageable element.. This seems like the kind of resolution we should make immediately. I.m copying to issues@omg.org . because we need a new issue bases on Maged.s original email .EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which in turn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense.. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 15 January 2010 21:19 To: Maged Elaasar Cc: Pete Rivett - Adaptive; uml2-rtf@omg.org Subject: RE: Enumeration Literal I also don.t particularly like EnumerationLiteral being a subclass of InstanceSpecification. However, I think changing this would be out of scope for this RTF. There are just too many issues that would have to be carefully considered, like the one Maged mentions below. Indeed, I think this is just the kind of issue that is the most dangerous for this RTF: something that seems like a good thing to do, but becomes more and more complicated to do right the more carefully you look at it. Whether or not you actual redefine classifier to a derived attribute, requiring the constraint .classifier = enumeration. seems to be a reasonable workaround for now. If, in addition, we make EnumerationLiteral::enumeration mandatory (I have no idea why it is 0..1 now), then an enumeration literal could not be owned by anything other than an enumeration, even if it is technically a packageable element. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, January 15, 2010 3:38 PM To: Maged Elaasar Cc: Pete Rivett - Adaptive; uml2-rtf@omg.org Subject: RE: Enumeration Literal Although.,,,,with the resolution in 8278, enum literal would not be a value spec, how would it still be assignable as a value to properties typed with the enumeration? Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 01/15/2010 03:35 PM To "Pete Rivett" cc uml2-rtf@omg.org Subject RE: Enumeration Literal Pete, I like the solution offered in 8278, i.e. making Enum Literal inherit from NamedElement with an optional 'value' attribute, but is it something we entertain in this RTF? If yes, that would be my choice too. However, I was going to propose making enum literal redefine 'classifier' to : /classifier:Enumeration [1] with a derivation classifier = enumeration. What do you think? "Pete Rivett" "Pete Rivett" 01/15/2010 03:19 PM To Maged Elaasar/Ottawa/IBM@IBMCA, cc Subject RE: Enumeration Literal Note that EnumerationLiteral::enumeration subsets NamedElement::namespace not PackageableElement::owningPackage (which itself also subsets NamedElement::namespace which is a derived union . which affects the interpretation of .subsets.). So I guess that means that a given EnumerationLiteral is either owned by an Enumeration or a Package (but not both of course). If owned by a Package then it could not even be connected to an Enumeration via the enumeration property (since that would imply dual ownership). An EnumerationLiteral without an Enumeration seems nonsense, hence treating it as a PackageableElement is also nonsense as you imply.. This is another example of where trying to do things at the property level (instead of simple patterns of association generalization) leaves us in confusion where even the experts are not clear what the specification means! Regardless of the above, I do not think EnumerationLiterals should be InstanceSpecifications at all! So even the .intended. inheritance is wrong! See Issue 8278 (which I raised in Feb 2005 complete with proposed resolution!). Adopting that proposal avoids the specific problem of EnumerationLiteral (but not the general one of a comprehensible specification). Also Issue 8274 is relevant. With regard to names being coupled to visibility, imports are also tied to naming (the only impact of an import is to make names usable without qualification). People often assume imports have more standing (e.g. that one should Import a Profile/package when referencing elements from it) and that might make sense . but it.s not what the specification says. This all reflects a programming language (where names matter) rather than a modeling mentality which does not reflect a lot of UML usage. [Aside: MOF explicitly ignores visibility and treats everything as public. It would be clearer if the UML metamodel reflected this and had all elements as public . looking at it recently I saw many were private] Regards Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 15 January 2010 11:01 To: uml2-rtf@omg.org Subject: Enumeration Literal Hello All, EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense. is it another case of unintended inheritance? Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: Cory Casanave , Pete Rivett - Adaptive , Ed Seidewitz , "Maged Elaasar" CC: "uml2-rtf@omg.org" Subject: RE: Enumeration Literal Thread-Topic: Enumeration Literal Thread-Index: AQHKliKPtm0CYPyJ/kCt5pCbZZJf95GXP9QAgAAXfoCAAA4ogIABESuAgAKs5RA= Date: Mon, 18 Jan 2010 10:23:29 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: I think one can make a case that enumeration literals can have slots. Consider an enumeration of KnownColours, for example {fred, green, blue, yellow, cyan, magenta, orange, gold, grey, etc} . each instance could carry its RGB values with it -> orange.redValue, etc. - Steve From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 16 January 2010 17:29 To: Pete Rivett - Adaptive; Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal It has always confounded me why we have of all the complexity of .instance specification. and .Enumeration Literals. instead of the simple and well defined concept of a regular instance. In that way an enumeration is just a class with a closed and enumerated extent of plain old instances. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 8:12 PM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and not one vendor got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 15 January 2010 16:21 To: Pete Rivett; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 5:57 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either . to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. [EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value. Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area . but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4. The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.) -- Ed From: Steve Cook To: Cory Casanave , Pete Rivett - Adaptive , Ed Seidewitz , "Maged Elaasar" CC: "uml2-rtf@omg.org" Subject: RE: Enumeration Literal Thread-Topic: Enumeration Literal Thread-Index: AQHKliKPtm0CYPyJ/kCt5pCbZZJf95GXP9QAgAAXfoCAAA4ogIABESuAgAKs5RA= Date: Mon, 18 Jan 2010 10:23:29 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.18.101816 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_70_90 0.1, SUPERLONG_LINE 0.05, BODY_SIZE_10000_PLUS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FRAUD_CONTACT_NAME 0, __HAS_HTML 0, __HAS_MSGID 0, __HTML_BOLD 0, __HTML_FONT_BLUE 0, __HTML_MSWORD 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STYLE_RATWARE_2 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NS ' X-PerlMx-SIL: Medium X-OriginalArrivalTime: 18 Jan 2010 10:24:11.0260 (UTC) FILETIME=[602483C0:01CA9828] I think one can make a case that enumeration literals can have slots. Consider an enumeration of KnownColours, for example {fred, green, blue, yellow, cyan, magenta, orange, gold, grey, etc} . each instance could carry its RGB values with it -> orange.redValue, etc. - Steve From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 16 January 2010 17:29 To: Pete Rivett - Adaptive; Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal It has always confounded me why we have of all the complexity of .instance specification. and .Enumeration Literals. instead of the simple and well defined concept of a regular instance. In that way an enumeration is just a class with a closed and enumerated extent of plain old instances. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 8:12 PM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and not one vendor got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 15 January 2010 16:21 To: Pete Rivett; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 5:57 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either . to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. [EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value. Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF I agree that there is a need for change in this area . but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4. The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.) -- Ed This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: "issues@omg.org" CC: "uml2-rtf@omg.org" Subject: RE: Enumeration Literal Thread-Topic: Enumeration Literal Thread-Index: AQHKliKPtm0CYPyJ/kCt5pCbZZJf95GXJGqAgAP8c7CAAH1mAA== Date: Mon, 18 Jan 2010 17:41:04 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: >because we need a new issue bases on Maged.s original email Correction . we do not need an issue . this is already 14631. - Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 18 January 2010 10:18 To: Ed Seidewitz; Maged Elaasar; issues@omg.org Cc: Pete Rivett - Adaptive; uml2-rtf@omg.org Subject: RE: Enumeration Literal > Whether or not you actual redefine classifier to a derived attribute, requiring the constraint .classifier = enumeration. seems to be a reasonable workaround for now. If, in addition, we make EnumerationLiteral::enumeration mandatory (I have no idea why it is 0..1 now), then an enumeration literal could not be owned by anything other than an enumeration, even if it is technically a packageable element.. This seems like the kind of resolution we should make immediately. I.m copying to issues@omg.org . because we need a new issue bases on Maged.s original email .EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which in turn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense.. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 15 January 2010 21:19 To: Maged Elaasar Cc: Pete Rivett - Adaptive; uml2-rtf@omg.org Subject: RE: Enumeration Literal I also don.t particularly like EnumerationLiteral being a subclass of InstanceSpecification. However, I think changing this would be out of scope for this RTF. There are just too many issues that would have to be carefully considered, like the one Maged mentions below. Indeed, I think this is just the kind of issue that is the most dangerous for this RTF: something that seems like a good thing to do, but becomes more and more complicated to do right the more carefully you look at it. Whether or not you actual redefine classifier to a derived attribute, requiring the constraint .classifier = enumeration. seems to be a reasonable workaround for now. If, in addition, we make EnumerationLiteral::enumeration mandatory (I have no idea why it is 0..1 now), then an enumeration literal could not be owned by anything other than an enumeration, even if it is technically a packageable element. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, January 15, 2010 3:38 PM To: Maged Elaasar Cc: Pete Rivett - Adaptive; uml2-rtf@omg.org Subject: RE: Enumeration Literal Although.,,,,with the resolution in 8278, enum literal would not be a value spec, how would it still be assignable as a value to properties typed with the enumeration? Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 01/15/2010 03:35 PM To "Pete Rivett" cc uml2-rtf@omg.org Subject RE: Enumeration Literal Pete, I like the solution offered in 8278, i.e. making Enum Literal inherit from NamedElement with an optional 'value' attribute, but is it something we entertain in this RTF? If yes, that would be my choice too. However, I was going to propose making enum literal redefine 'classifier' to : /classifier:Enumeration [1] with a derivation classifier = enumeration. What do you think? "Pete Rivett" "Pete Rivett" 01/15/2010 03:19 PM To Maged Elaasar/Ottawa/IBM@IBMCA, cc Subject RE: Enumeration Literal Note that EnumerationLiteral::enumeration subsets NamedElement::namespace not PackageableElement::owningPackage (which itself also subsets NamedElement::namespace which is a derived union . which affects the interpretation of .subsets.). So I guess that means that a given EnumerationLiteral is either owned by an Enumeration or a Package (but not both of course). If owned by a Package then it could not even be connected to an Enumeration via the enumeration property (since that would imply dual ownership). An EnumerationLiteral without an Enumeration seems nonsense, hence treating it as a PackageableElement is also nonsense as you imply.. This is another example of where trying to do things at the property level (instead of simple patterns of association generalization) leaves us in confusion where even the experts are not clear what the specification means! Regardless of the above, I do not think EnumerationLiterals should be InstanceSpecifications at all! So even the .intended. inheritance is wrong! See Issue 8278 (which I raised in Feb 2005 complete with proposed resolution!). Adopting that proposal avoids the specific problem of EnumerationLiteral (but not the general one of a comprehensible specification). Also Issue 8274 is relevant. With regard to names being coupled to visibility, imports are also tied to naming (the only impact of an import is to make names usable without qualification). People often assume imports have more standing (e.g. that one should Import a Profile/package when referencing elements from it) and that might make sense . but it.s not what the specification says. This all reflects a programming language (where names matter) rather than a modeling mentality which does not reflect a lot of UML usage. [Aside: MOF explicitly ignores visibility and treats everything as public. It would be clearer if the UML metamodel reflected this and had all elements as public . looking at it recently I saw many were private] Regards Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 15 January 2010 11:01 To: uml2-rtf@omg.org Subject: Enumeration Literal Hello All, EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense. is it another case of unintended inheritance? Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: Enumeration Literal Date: Mon, 18 Jan 2010 17:06:40 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enumeration Literal thread-index: AcqYhqiCB8vlpQUrSR2R06ZT75TaNAAASIIQ From: "Cory Casanave" To: "Bran Selic" Cc: "Pete Rivett - Adaptive" , "Ed Seidewitz" , "Maged Elaasar" , Brand, Re: Enumeration literals should be values, not object instances.: Why? Why Can.t I enumerate the branches of U.S. government . which all would consider as identifiable objects? Or, what about an enumerated set of composite data types? I see no reason to limit an enumerated set to an enumeration of values. To me, this is another example of an over-constrained model introducing complexity and confusion. However, that does not speak to the reason why we can.t just use ordinary, every day, instances . including value instances, as the enumerated extent of a type. This would be so much simpler. Note: I am not suggesting a change for 2.4. -Cory -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Sunday, January 17, 2010 2:49 PM To: Cory Casanave Cc: Pete Rivett - Adaptive; Ed Seidewitz; Maged Elaasar; uml2-rtf@omg.org Subject: Re: Enumeration Literal Cory, This goes back to an almost ancient discussion about the difference between objects, which have identity, and values, which do not. Enumeration literals shoud be values, not object instances. Cheers...Bran On Sat, Jan 16, 2010 at 12:29 PM, Cory Casanave wrote: It has always confounded me why we have of all the complexity of .instance specification. and .Enumeration Literals. instead of the simple and well defined concept of a regular instance. In that way an enumeration is just a class with a closed and enumerated extent of plain old instances. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 8:12 PM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal Apologies I meant to say .create a dummy InstanceValue.. Not a lot of work but clumsy. And not very obvious To back up the latter statement, after my earlier email I went through the use of EnumerationLiterals in the Model Interchange Working Group XMI files and not one vendor got it perfectly right in both the definition of the Enumeration and using the literal as a default parameter value. See the MIWG issues I raised for more information. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 15 January 2010 16:21 To: Pete Rivett; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal Pete -- -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 15, 2010 5:57 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Enumeration Literal As things currently stand EnumerationLiteral is not a ValueSpecification either . to assign it (e.g. as default for a Property) one would need to create a dummy InstanceSpecification and reference the EnumerationLiteral via the instance property. This is a further argument for a change in this area. [EVS] Actually, all you need to do currently is create an InstanceValue (which is a ValueSpecification) and point it to the EnumerationLiteral. This is the same way you currently use any kind of InstanceSpecification as a value. Again, I think the very fact that we need to have a discussion like this to think things out indicates that this is not something that should be in the scope of this RTF. I agree that there is a need for change in this area . but there is a need for change in a lot of areas. Fixing them was pointedly not what we where trying to do in the scope of 2.4. The current situation may not be pretty, but I just don.t think it is a .showstopper. issue. (Getting things correct in the XMI, however, definitely is within our scope.) -- Ed Subject: RE: Enumeration Literal Date: Mon, 18 Jan 2010 17:39:26 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enumeration Literal thread-index: AcqYil3dJN/rCnAQSICXO25uOgTlvgAA+qcg From: "Cory Casanave" To: "Andre Cusson" , "Bran Selic" Cc: "Pete Rivett - Adaptive" , "Ed Seidewitz" , "Maged Elaasar" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o0IMXFYD009596 Andre, I agree that "self identifying" or saying that the identity is the same as the value is a better mindset than saying that values don't have identity. What we want to say is that the number 5 has the same identity, everywhere. In all other respects we should be able to treat it like any other instance (and enumerate values or identifiable objects). The technical object/primitive value distinction goes back to (some) OO languages and is, in my mind, unnecessary and complex. It was introduced for efficiency in the execution machines so we could keep "int" around. I kind of have a soft spot in my heart for int as well - but it is still an instance of a class. -Cory -----Original Message----- From: Andre Cusson [mailto:acusson@01COMMUNICATIONS.com] Sent: Sunday, January 17, 2010 3:25 PM To: Bran Selic Cc: Cory Casanave; Pete Rivett - Adaptive; Ed Seidewitz; Maged Elaasar; uml2-rtf@omg.org Subject: Re: Enumeration Literal Hi, Assuming a value may not have an identity, shouldn't the enumeration, a value holding structure/concept/resource have one? Is a value list a value and if so, is a value record (e.g. record instance) a value also? if so, then anything can be a value and values can also be identified (and objects can also be unidentified!). Doesn't it seem like only atomic values could "not have identity", not precluding the fact that they may still have identity (e.g. variable, parameter, attribute, property). I would even go as far as to say that everything has identity and that some values are self identifying (e.g. literals), in given contexts. Maybe the Object-Oriented view that objects have identity and values do not, is a little "ancient", as you say. Cheers, Andre > Cory, > > This goes back to an almost ancient discussion about the difference > between objects, which have identity, and values, which do not. > > Enumeration literals shoud be values, not object instances. > > Cheers...Bran > > On Sat, Jan 16, 2010 at 12:29 PM, Cory Casanave > > wrote: > > It has always confounded me why we have of all the complexity of > "instance specification" and "Enumeration Literals" instead of the > simple and well defined concept of a regular instance. In that > way an enumeration is just a class with a closed and enumerated > extent of plain old instances. > > -Cory > > > > ------------------------------------------------------------------------ > > *From:* Pete Rivett [mailto:pete.rivett@adaptive.com > ] > *Sent:* Friday, January 15, 2010 8:12 PM > *To:* Ed Seidewitz; Maged Elaasar > > *Cc:* uml2-rtf@omg.org > *Subject:* RE: Enumeration Literal > > > > Apologies I meant to say 'create a dummy InstanceValue'. > > Not a lot of work but clumsy. > > > > And not very obvious > > To back up the latter statement, after my earlier email I went > through the use of EnumerationLiterals in the Model Interchange > Working Group XMI files and _not one vendor_ got it perfectly > right in both the definition of the Enumeration and using the > literal as a default parameter value. See the MIWG issues I raised > for more information. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com > ] > *Sent:* 15 January 2010 16:21 > *To:* Pete Rivett; Maged Elaasar > *Cc:* uml2-rtf@omg.org > *Subject:* RE: Enumeration Literal > > > > Pete -- > > > > ------------------------------------------------------------------------ > > *From:* Pete Rivett [mailto:pete.rivett@adaptive.com > ] > *Sent:* Friday, January 15, 2010 5:57 PM > *To:* Maged Elaasar > *Cc:* uml2-rtf@omg.org > *Subject:* RE: Enumeration Literal > > > > As things currently stand EnumerationLiteral is not a > ValueSpecification either - to assign it (e.g. as default for a > Property) one would need to create a dummy InstanceSpecification > and reference the EnumerationLiteral via the instance property. > > This is a further argument for a change in this area. > > > > */[EVS] Actually, all you need to do currently is create an > InstanceValue (which is a ValueSpecification) and point it to the > EnumerationLiteral. This is the same way you currently use any > kind of InstanceSpecification as a value./* > > */ /* > > */Again, I think the very fact that we need to have a discussion > like this to think things out indicates that this is not something > that should be in the scope of this RTF. I agree that there is a > need for change in this area - but there is a need for change in a > lot of areas. Fixing them was pointedly not what we where trying > to do in the scope of 2.4./* > > */ /* > > */The current situation may not be pretty, but I just don't think > it is a "showstopper" issue. (Getting things correct in the XMI, > however, definitely is within our scope.)/* > > */ /* > > */-- Ed/* > > X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Jan 2010 06:55:04 -0500 To: Maged Elaasar , uml2-rtf@omg.org From: Juergen Boldt Subject: Re: Enumeration Literal should handle this thread as an issue or is it 'just' discussion? -Juergen At 02:00 PM 1/15/2010, Maged Elaasar wrote: Hello All, EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense. is it another case of unintended inheritance? Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement? Thanks, Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Tue, 19 Jan 2010 13:11:47 -0500 Subject: RE: Enumeration Literal Thread-Topic: Enumeration Literal Thread-Index: AcqWIqz2QOYQVwJjQYuXzqHTfq1EmAADWrRAAARD/dAAAcR7AAAiJaEAAJhh61A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o0JI66kZ007657 Cory, > It has always confounded me why we have of all the > complexity of "instance specification" and "Enumeration > Literals" instead of the simple and well defined concept of > a regular instance. Instances aren't so simple. They're often records of actual physical things (because the physical things don't fit in the computer). As such, multiple "instances" can refer to the same physical thing. This is true in OWL and UML. UML also allows "instances" to refer to multiple physical things (whereas OWL individuals refer to exactly one physical thing). This is why UML calls them instance *specifications*. They only specify instances, they aren't instances, and can't be in many applications. Conrad X-IronPort-AV: E=Sophos;i="4.49,305,1262559600"; d="scan'208";a="22348079" From: LONJON Antoine To: "Bock, Conrad" , "uml2-rtf@omg.org" Date: Tue, 19 Jan 2010 19:19:39 +0100 Subject: RE: Enumeration Literal Thread-Topic: Enumeration Literal Thread-Index: AcqWIqz2QOYQVwJjQYuXzqHTfq1EmAADWrRAAARD/dAAAcR7AAAiJaEAAJhh61AAAEnlsA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o0JIGUhm009024 Aren't there two kinds of "instance". The one in the universe of discourse that refer to the other one: things in the real world. Isn't what is classified by classes things in the universe of discourse rather than things of the real world? Antoine -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Tuesday, January 19, 2010 7:12 PM To: uml2-rtf@omg.org Subject: RE: Enumeration Literal Cory, > It has always confounded me why we have of all the > complexity of "instance specification" and "Enumeration > Literals" instead of the simple and well defined concept of > a regular instance. Instances aren't so simple. They're often records of actual physical things (because the physical things don't fit in the computer). As such, multiple "instances" can refer to the same physical thing. This is true in OWL and UML. UML also allows "instances" to refer to multiple physical things (whereas OWL individuals refer to exactly one physical thing). This is why UML calls them instance *specifications*. They only specify instances, they aren't instances, and can't be in many applications. Conrad This e-mail, including attachments, is confidential. It is intended solely for the addressees. If you are not a recipient, any use, copy or diffusion, even in part of this message is prohibited. Please delete it and notify the sender immediately. Since the integrity of this message cannot be guaranteed on the Internet, MEGA cannot be considered liable for its content. From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Tue, 19 Jan 2010 13:37:20 -0500 Subject: RE: Enumeration Literal Thread-Topic: Enumeration Literal Thread-Index: AcqWIqz2QOYQVwJjQYuXzqHTfq1EmAADWrRAAARD/dAAAcR7AAAiJaEAAJhh61AAAEnlsAAAlXjA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o0JIVPUv011486 Antoine, > Aren't there two kinds of "instance". The one in the universe of > discourse that refer to the other one: things in the real world. If you mean UoD as in model theory, I was using "physical things" as the objects in the UoD. These and other things in the UoD are used to interpret the model constructed by the user (in the OMG sense). For example, a UML instance spec is potentially interpreted as zero to many objects in the UoD, while OWL individuals are interpreted as exactly one. Conrad