Issue 8069: What happened to real numbers (uml2-rtf) Source: (, ) Nature: Clarification Severity: Minor Summary: The elements for numbers you define in the Literals package are LiteralInteger and LiteralUnlimitedNatural. What happened to real numbers? Natural numbers do no include decimals. Resolution: Revised Text: Actions taken: January 4, 2005: received issue August 23, 2006: closed issue Discussion: The Literals package is necessary to use the built-in primitive types Integer, String, UnlimitedNatural, and Boolean. The Literal classes map values in value specifications to the appropriate primitive type. All other number types that are not built-in can be defined by introducing a new primitive type, e.g. primitive type Real. These user-defined types are integrated into value specifications via the instance value class. Disposition: Closed, no change End of Annotations:===== m: webmaster@omg.org Date: 04 Jan 2005 11:59:07 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jane Messenger Company: U. S. Geological Survey mailFrom: jmessenger@usgs.gov Notification: Yes Specification: Infrastructure Section: 9.10 FormalNumber: ptc/03-09-15 Version: 2.0 RevisionDate: 12/01/2003 Page: 66 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description The elements for numbers you define in the Literals package are LiteralInteger and LiteralUnlimitedNatural. What happened to real numbers? Natural numbers do no include decimals. Subject: RE: Draft of Ballot 3 Date: Mon, 9 May 2005 09:48:14 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of Ballot 3 thread-index: AcVUPO0khAqCgtdMTs6FnRHPcXWONgALQLzw From: "Tim Weilkiens" To: "Branislav Selic" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j497r6hh017112 Bran, my comments: Issue 8069: I disagree that it is easy to add Reals to UML. See issue 7947 that emerges from SysML work. Issue 8107: Reference is on page 171. Seems to be resolved by the FTF. Tim > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Monday, May 09, 2005 4:08 AM > To: uml2-rtf@omg.org > Subject: Draft of Ballot 3 > > > Slightly under plan (56 proposed resolutions < goal of > 60/ballot), but not too too bad. Thanks to all those who > contributed this time around: Ed, Conrad, Chris, Eran, Jim, > Bran (apologies if I missed someone). > > The formal ballot opens next Friday, so please review these > proposals BEFORE then, to see if you agree with them. > > Any proposals that come in after this will be slated for ballot 4. > > > > Cheers, > > Bran To: "Tim Weilkiens" Cc: uml2-rtf@omg.org Subject: RE: Draft of Ballot 3 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 9 May 2005 09:51:52 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.53HF247 | January 6, 2005) at 05/09/2005 09:51:53, Serialize complete at 05/09/2005 09:51:53 Thanks, Tim. SysML has added Reals, which is perfectly fine and which, in my mind, confirms what is stated in the proposed resolution: Reals can be added where they are needed. So, I see no reason to add it to base UML. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Tim Weilkiens" 05/09/2005 03:48 AM To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: Draft of Ballot 3 Bran, my comments: Issue 8069: I disagree that it is easy to add Reals to UML. See issue 7947 that emerges from SysML work. Issue 8107: Reference is on page 171. Seems to be resolved by the FTF. Tim > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Monday, May 09, 2005 4:08 AM > To: uml2-rtf@omg.org > Subject: Draft of Ballot 3 > > > Slightly under plan (56 proposed resolutions < goal of > 60/ballot), but not too too bad. Thanks to all those who > contributed this time around: Ed, Conrad, Chris, Eran, Jim, > Bran (apologies if I missed someone). > > The formal ballot opens next Friday, so please review these > proposals BEFORE then, to see if you agree with them. > > Any proposals that come in after this will be slated for ballot 4. > > > > Cheers, > > Bran > Issue 8069: What happened to real numbers (uml2-rtf) Click here for this issue's archive. Nature: Clarification Severity: Minor Summary: The elements for numbers you define in the Literals package are LiteralInteger and LiteralUnlimitedNatural. What happened to real numbers? Natural numbers do no include decimals. Resolution: Resolved Revised Text: - Add the following section after 17.4.2: Real (from PrimitiveTypes) A real is a primitive type representing real numbers. Generalizations . none Description An instance of Real is an element in the (infinite) set of real numbers (1.5, 3.14, .) to measure continuous quantities. Attributes No additional attributes. Associations No additional associations. Constraints No additional constraints. Semantics Real is an instance of PrimitiveType. Notation Real will appear as the type of attributes in the metamodel. Real instances will be values associated to slots such as .2.3, 3.14, 4.2 etc. - Add primitive type Real to fig. 422. - Add class LiteralReal with attribute value:Real as subclass of LiteralSpecification to fig. 6.- Add the following section to chapter 7 LiteralReal (from Kernel) A literal real is a specification of an real value. Generalizations . .LiteralSpecification (from Kernel). on page 94 Description A literal real contains a Real-valued attribute. Attributes . value: Real The specified Real value. Associations No additional associations. Constraints No additional constraints. Additional Operations [1] The query isComputable() is redefined to be true. LiteralReal::isComputable(): Boolean; isComputable = true [2] The query realValue() gives the value. LiteralReal::realValue() : [Real]; realValue = value Semantics A LiteralReal specifies a constant Real value. Notation A LiteralReal is shown as a sequence of digits. The decimal and the fractional part are separated by a To: "Tim Weilkiens" Cc: uml2-rtf@omg.org Subject: Re: Primitive Type Real X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 19 Jul 2005 17:20:44 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/19/2005 17:20:46, Serialize complete at 07/19/2005 17:20:46 Tim, > Other than for example Interger, Real is not used in the metamodel. We > introduce > the primitive type since it is not easy to introduce a user-defined real > since the > ValueSpecification model has no LiteralReal. Would it, perhaps, make more sense to just introduce a LiteralPrimitiveType with an attribute "value:String"? That would cover other potential primitive types and would not require us to define Real in the spec itself. The main concern I have with the latter is that, however we define Real, it is highly likely that someone will be unhappy with it; there is so much variability there (concrete syntax, resolution, precision, operations, etc.). This would allow profiles to define Real and other primitive types any way they like. Bran Subject: RE: Primitive Type Real Date: Wed, 20 Jul 2005 01:08:03 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Primitive Type Real Thread-Index: AcWMqpHH9Ds0QsqFQhKqoJYdyxK+sgAOx9PA From: "Pete Rivett" To: "Branislav Selic" , "Tim Weilkiens" Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com Real (actually Double) is used in the Diagram Interchange metamodel. I think it should be added to PrimitiveTypes: it was in MOF 1.4 after all and there is a standard for its representation with sensible mappings to most programming languages and XML Schema. However I agree with Bran about simplifying the model for Literals. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, July 19, 2005 5:21 PM To: Tim Weilkiens Cc: uml2-rtf@omg.org Subject: Re: Primitive Type Real Tim, > Other than for example Interger, Real is not used in the metamodel. We > introduce > the primitive type since it is not easy to introduce a user-defined real > since the > ValueSpecification model has no LiteralReal. Would it, perhaps, make more sense to just introduce a LiteralPrimitiveType with an attribute "value:String"? That would cover other potential primitive types and would not require us to define Real in the spec itself. The main concern I have with the latter is that, however we define Real, it is highly likely that someone will be unhappy with it; there is so much variability there (concrete syntax, resolution, precision, operations, etc.). This would allow profiles to define Real and other primitive types any way they like. Bran Reply-To: Joaquin Miller X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 20 Jul 2005 16:50:00 -0700 To: UML-RTF From: Joaquin Miller Subject: RE: Primitive Type Real Real (actually Double) is used in the Diagram Interchange metamodel. I think it should be added to PrimitiveTypes: it was in MOF 1.4 after all and there is a standard for its representation with sensible mappings to most programming languages and XML Schema. Let's do include whatever is required for the diagram interchange model. Could we please call this something like Float (or Double)? These never were real numbers and the name, 'Real', which was always wrong, is now also old fashioned. The nice thing about 'Float' (besides being an accurate name for these numbers) is that it immediately brings to mind the accepted standard for floating point numbers. The argument against it is that if we have Float then UML (or diagram exchange) also needs Double for specificity, two types where only one is required. That's not a big burden, but, if this argument prevails, let's use the name, 'Double'. (The best name would be 'Rational', but there are two problems: people would think we were some kind of purists or something, and the other problem. I would vote for 'Rational', as, though not as specific as 'Float' or 'Double', being at the exactly correct level of abstraction for UML. Then Diagram Exchange will (as in any case) need to specify the representation used for Rational.) Cordially, Joaquin Subject: 8069: Draft version of PrimitiveType Real resolution Date: Mon, 15 Aug 2005 16:06:54 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8069: Draft version of PrimitiveType Real resolution thread-index: AcWhopbw0+WQ6uzlRDCi8NQz4jG2sw== From: "Tim Weilkiens" To: "uml2rtf" Attached is a first sketch of a resolution for issue 8069 (PrimitiveType real). The proposal contains the new metaclass LiteralPrimitiveType instead of the several LiteralXY classes. It doesn't contain a new primitive type. With the new LiteralPrimitiveType class it is easy to define a new PrimitiveType Real. I can't see that it is necessary that UML predefines that type. It was stated in the previous discussion that UML needs a primitive type Real for the Diagram Interchange. I couldn't follow that argument. We have a diagram interchange format (as a proposal) now and we have a UML without a Real datatype. Please comment! Tim --- Tim Weilkiens, E-Mail tim.weilkiens@oose.de Instructor, Consultant, Coach OMG Representative, INCOSE member oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet http://www.oose.de resolvedIssues_real.doc Subject: RE: 8069: Draft version of PrimitiveType Real resolution Date: Wed, 17 Aug 2005 10:14:46 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8069: Draft version of PrimitiveType Real resolution thread-index: AcWhrNQKDTJVE7ZNRPOiibWZLYbBjABVOREg From: "Tim Weilkiens" To: "Kenneth Hussey" Cc: "uml2rtf" Kenn, Comment are inline. > Is it true that literal specifications always represent > primitive types? I'd prefer if the name > "LiteralSpecification" were kept (i.e. if > LiteralSpecification were simply made conrete and the > subclasses removed). Ok. That's more general and we use a class that already exists. Attached you'll find the updated version. > I'm not sure I'm comfortable with the loss of LiteralNull. > Perhaps the isNull property could be retained (moved to > LiteralSpecification) and set to true only if the value > represents NULL. Similarly, the isComputable property > could/should be retained (moved to LiteralSpecification). Where do you need isNull and is Computable? > > > "Tim Weilkiens" > > 08/15/2005 10:06 AM To > "uml2rtf" > cc > Subject > 8069: Draft version of PrimitiveType Real resolution > > > > > > > Attached is a first sketch of a resolution for issue 8069 > (PrimitiveType > real). > > The proposal contains the new metaclass LiteralPrimitiveType > instead of > the several LiteralXY classes. > It doesn't contain a new primitive type. With the new > LiteralPrimitiveType class > it is easy to define a new PrimitiveType Real. I can't see that it is > necessary that > UML predefines that type. > > It was stated in the previous discussion that UML needs a > primitive type > Real for > the Diagram Interchange. I couldn't follow that argument. We have a > diagram interchange > format (as a proposal) now and we have a UML without a Real datatype. > > Please comment! > > Tim > > --- > Tim Weilkiens, E-Mail tim.weilkiens@oose.de > Instructor, Consultant, Coach > OMG Representative, INCOSE member > oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet > http://www.oose.de > [attachment "resolvedIssues_real.doc" deleted by Kenneth > Hussey/Ottawa/IBM] > > resolvedIssues_real1.doc To: "uml2rtf" Subject: RE: 8069: Draft version of PrimitiveType Real resolution X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Wed, 17 Aug 2005 09:39:55 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/17/2005 09:39:57, Serialize complete at 08/17/2005 09:39:57 Tim, Note that LiteralSpecification also needs to be made concrete. The isNull attribute is useful, for example, for distinguishing between an explicit NULL and a literal strings with an unspecified value. Regardless, I don't think we can remove these properties (isNull and isComputable) without justification as part of an RTF - this kind of change could be considered more than a "revision" (not to mention the fact that existing tools may already have a dependency on these properties). Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Tim Weilkiens" 08/17/2005 04:14 AM To Kenneth Hussey/Ottawa/IBM@IBMCA cc "uml2rtf" Subject RE: 8069: Draft version of PrimitiveType Real resolution Kenn, Comment are inline. > Is it true that literal specifications always represent > primitive types? I'd prefer if the name > "LiteralSpecification" were kept (i.e. if > LiteralSpecification were simply made conrete and the > subclasses removed). Ok. That's more general and we use a class that already exists. Attached you'll find the updated version. > I'm not sure I'm comfortable with the loss of LiteralNull. > Perhaps the isNull property could be retained (moved to > LiteralSpecification) and set to true only if the value > represents NULL. Similarly, the isComputable property > could/should be retained (moved to LiteralSpecification). Where do you need isNull and is Computable? > > > "Tim Weilkiens" > > 08/15/2005 10:06 AM To > "uml2rtf" > cc > Subject > 8069: Draft version of PrimitiveType Real resolution > > > > > > > Attached is a first sketch of a resolution for issue 8069 > (PrimitiveType > real). > > The proposal contains the new metaclass LiteralPrimitiveType > instead of > the several LiteralXY classes. > It doesn't contain a new primitive type. With the new > LiteralPrimitiveType class > it is easy to define a new PrimitiveType Real. I can't see that it is > necessary that > UML predefines that type. > > It was stated in the previous discussion that UML needs a > primitive type > Real for > the Diagram Interchange. I couldn't follow that argument. We have a > diagram interchange > format (as a proposal) now and we have a UML without a Real datatype. > > Please comment! > > Tim > > --- > Tim Weilkiens, E-Mail tim.weilkiens@oose.de > Instructor, Consultant, Coach > OMG Representative, INCOSE member > oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet > http://www.oose.de > [attachment "resolvedIssues_real.doc" deleted by Kenneth > Hussey/Ottawa/IBM] > > [attachment "resolvedIssues_real.doc" deleted by Kenneth Hussey/Ottawa/IBM] Subject: RE: 8069: Draft version of PrimitiveType Real resolution Date: Wed, 17 Aug 2005 16:04:24 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8069: Draft version of PrimitiveType Real resolution thread-index: AcWjMY/x11xGeAsVSHyWfgz56gDLwAAAiOcg From: "Tim Weilkiens" To: "Kenneth Hussey" , "uml2rtf" Kenn, > Note that LiteralSpecification also needs to be made concrete. Done. > The isNull attribute is useful, for example, for > distinguishing between an explicit NULL and a literal strings > with an unspecified value. Regardless, I don't think we can > remove these properties (isNull and isComputable) without > justification as part of an RTF - this kind of change could > be considered more than a "revision" (not to mention the fact > that existing tools may already have a dependency on these > properties). > isNull and isComputable (and several more) are inherited from ValueSpecification. They are still there. The question is: Is a LiteralSpecification always computable? I think yes, so we should redefine the query isComputable appropriately. I am surprised that ValueSpecification has additional operations like stringValue(), integerValue(), and so on. Again we have an implicit dependency to the predefined primitive types here. What about real? Do we need another additional operation realValue()? Or do we need the xyValue() operations at all? Where they are used? Tim > > "Tim Weilkiens" > > 08/17/2005 04:14 AM To > Kenneth Hussey/Ottawa/IBM@IBMCA > cc > "uml2rtf" > Subject > RE: 8069: Draft version of PrimitiveType Real resolution > > > > > > > Kenn, > > Comment are inline. > > > Is it true that literal specifications always represent > > primitive types? I'd prefer if the name > > "LiteralSpecification" were kept (i.e. if > > LiteralSpecification were simply made conrete and the > > subclasses removed). > > Ok. That's more general and we use a class that already exists. > Attached you'll find the updated version. > > > I'm not sure I'm comfortable with the loss of LiteralNull. > > Perhaps the isNull property could be retained (moved to > > LiteralSpecification) and set to true only if the value > > represents NULL. Similarly, the isComputable property > > could/should be retained (moved to LiteralSpecification). > > Where do you need isNull and is Computable? > > > > > > > "Tim Weilkiens" > > > > 08/15/2005 10:06 AM To > > "uml2rtf" > > cc > > Subject > > 8069: Draft version of PrimitiveType Real resolution > > > > > > > > > > > > > > Attached is a first sketch of a resolution for issue 8069 > > (PrimitiveType > > real). > > > > The proposal contains the new metaclass LiteralPrimitiveType > > instead of > > the several LiteralXY classes. > > It doesn't contain a new primitive type. With the new > > LiteralPrimitiveType class > > it is easy to define a new PrimitiveType Real. I can't see > that it is > > necessary that > > UML predefines that type. > > > > It was stated in the previous discussion that UML needs a > > primitive type > > Real for > > the Diagram Interchange. I couldn't follow that argument. We have a > > diagram interchange > > format (as a proposal) now and we have a UML without a Real > datatype. > > > > Please comment! > > > > Tim > > > > --- > > Tim Weilkiens, E-Mail tim.weilkiens@oose.de > > Instructor, Consultant, Coach > > OMG Representative, INCOSE member > > oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet > > http://www.oose.de > > [attachment "resolvedIssues_real.doc" deleted by Kenneth > > Hussey/Ottawa/IBM] > > > > > [attachment "resolvedIssues_real.doc" deleted by Kenneth > Hussey/Ottawa/IBM] > > resolvedIssues_real2.doc To: "uml2rtf" Subject: RE: 8069: Draft version of PrimitiveType Real resolution X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Wed, 17 Aug 2005 16:35:12 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/17/2005 16:35:13, Serialize complete at 08/17/2005 16:35:13 Tim, I believe all literal specifications are computable, so the isComputable() query could perhaps be redefined to return true in LiteralSpecification. All value specifications are not null except for literal null, so either we would need to keep LiteralNull or redefined isNull to be based on the value of a property in LiteralSpecification. Yes, these other operation presume the existence of the built-in literal types (the operations are redefined in each subtype to return the appropriate result). I believe that adding a realValue() operation would defeat your purpose, so perhaps these additional (type-specific) operations need to be removed. I am concerned, however, what impact this may have have on existing tools... Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Tim Weilkiens" 08/17/2005 10:04 AM To Kenneth Hussey/Ottawa/IBM@IBMCA, "uml2rtf" cc Subject RE: 8069: Draft version of PrimitiveType Real resolution Kenn, > Note that LiteralSpecification also needs to be made concrete. Done. > The isNull attribute is useful, for example, for > distinguishing between an explicit NULL and a literal strings > with an unspecified value. Regardless, I don't think we can > remove these properties (isNull and isComputable) without > justification as part of an RTF - this kind of change could > be considered more than a "revision" (not to mention the fact > that existing tools may already have a dependency on these > properties). > isNull and isComputable (and several more) are inherited from ValueSpecification. They are still there. The question is: Is a LiteralSpecification always computable? I think yes, so we should redefine the query isComputable appropriately. I am surprised that ValueSpecification has additional operations like stringValue(), integerValue(), and so on. Again we have an implicit dependency to the predefined primitive types here. What about real? Do we need another additional operation realValue()? Or do we need the xyValue() operations at all? Where they are used? Tim > > "Tim Weilkiens" > > 08/17/2005 04:14 AM To > Kenneth Hussey/Ottawa/IBM@IBMCA > cc > "uml2rtf" > Subject > RE: 8069: Draft version of PrimitiveType Real resolution > > > > > > > Kenn, > > Comment are inline. > > > Is it true that literal specifications always represent > > primitive types? I'd prefer if the name > > "LiteralSpecification" were kept (i.e. if > > LiteralSpecification were simply made conrete and the > > subclasses removed). > > Ok. That's more general and we use a class that already exists. > Attached you'll find the updated version. > > > I'm not sure I'm comfortable with the loss of LiteralNull. > > Perhaps the isNull property could be retained (moved to > > LiteralSpecification) and set to true only if the value > > represents NULL. Similarly, the isComputable property > > could/should be retained (moved to LiteralSpecification). > > Where do you need isNull and is Computable? > > > > > > > "Tim Weilkiens" > > > > 08/15/2005 10:06 AM To > > "uml2rtf" > > cc > > Subject > > 8069: Draft version of PrimitiveType Real resolution > > > > > > > > > > > > > > Attached is a first sketch of a resolution for issue 8069 > > (PrimitiveType > > real). > > > > The proposal contains the new metaclass LiteralPrimitiveType > > instead of > > the several LiteralXY classes. > > It doesn't contain a new primitive type. With the new > > LiteralPrimitiveType class > > it is easy to define a new PrimitiveType Real. I can't see > that it is > > necessary that > > UML predefines that type. > > > > It was stated in the previous discussion that UML needs a > > primitive type > > Real for > > the Diagram Interchange. I couldn't follow that argument. We have a > > diagram interchange > > format (as a proposal) now and we have a UML without a Real > datatype. > > > > Please comment! > > > > Tim > > > > --- > > Tim Weilkiens, E-Mail tim.weilkiens@oose.de > > Instructor, Consultant, Coach > > OMG Representative, INCOSE member > > oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet > > http://www.oose.de > > [attachment "resolvedIssues_real.doc" deleted by Kenneth > > Hussey/Ottawa/IBM] > > > > > [attachment "resolvedIssues_real.doc" deleted by Kenneth > Hussey/Ottawa/IBM] > > [attachment "resolvedIssues_real.doc" deleted by Kenneth Hussey/Ottawa/IBM] To: "uml2rtf" Subject: RE: 8069: Draft version of PrimitiveType Real resolution X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Wed, 17 Aug 2005 09:39:55 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/17/2005 09:39:57, Serialize complete at 08/17/2005 09:39:57 Tim, Note that LiteralSpecification also needs to be made concrete. The isNull attribute is useful, for example, for distinguishing between an explicit NULL and a literal strings with an unspecified value. Regardless, I don't think we can remove these properties (isNull and isComputable) without justification as part of an RTF - this kind of change could be considered more than a "revision" (not to mention the fact that existing tools may already have a dependency on these properties). Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Tim Weilkiens" 08/17/2005 04:14 AM To Kenneth Hussey/Ottawa/IBM@IBMCA cc "uml2rtf" Subject RE: 8069: Draft version of PrimitiveType Real resolution Kenn, Comment are inline. > Is it true that literal specifications always represent > primitive types? I'd prefer if the name > "LiteralSpecification" were kept (i.e. if > LiteralSpecification were simply made conrete and the > subclasses removed). Ok. That's more general and we use a class that already exists. Attached you'll find the updated version. > I'm not sure I'm comfortable with the loss of LiteralNull. > Perhaps the isNull property could be retained (moved to > LiteralSpecification) and set to true only if the value > represents NULL. Similarly, the isComputable property > could/should be retained (moved to LiteralSpecification). Where do you need isNull and is Computable? > > > "Tim Weilkiens" > > 08/15/2005 10:06 AM To > "uml2rtf" > cc > Subject > 8069: Draft version of PrimitiveType Real resolution > > > > > > > Attached is a first sketch of a resolution for issue 8069 > (PrimitiveType > real). > > The proposal contains the new metaclass LiteralPrimitiveType > instead of > the several LiteralXY classes. > It doesn't contain a new primitive type. With the new > LiteralPrimitiveType class > it is easy to define a new PrimitiveType Real. I can't see that it is > necessary that > UML predefines that type. > > It was stated in the previous discussion that UML needs a > primitive type > Real for > the Diagram Interchange. I couldn't follow that argument. We have a > diagram interchange > format (as a proposal) now and we have a UML without a Real datatype. > > Please comment! > > Tim > > --- > Tim Weilkiens, E-Mail tim.weilkiens@oose.de > Instructor, Consultant, Coach > OMG Representative, INCOSE member > oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet > http://www.oose.de > [attachment "resolvedIssues_real.doc" deleted by Kenneth > Hussey/Ottawa/IBM] > > [attachment "resolvedIssues_real.doc" deleted by Kenneth Hussey/Ottawa/IBM] Subject: RE: 8069: Draft version of PrimitiveType Real resolution Date: Wed, 24 Aug 2005 13:50:38 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8069: Draft version of PrimitiveType Real resolution thread-index: AcWja3+mNQZzf9KBQHCL1kYmZFptAQFM9/sA From: "Tim Weilkiens" To: "Kenneth Hussey" , "uml2rtf" , "Branislav Selic" Kenn, it isn't easy to remove the XYZvalue()-operations from ValueSpecification. They are used in the specification at other places (MultiplicityElement). They are necessary to map ValueSpecification values to a primitive type value. Now I'm back from where I started. There is one othere branch I can follow: introducing primitive type Real and a LiteralReal. But that's only a solution for Real. What about Complex? I think I've found another way. The original problem was that it is not possible to define a primitive type Real, because there is no LiteralReal. I believe that can be simply solved by using an instance value to use real values in ValueSpecifications. Therefore the issue can be closed without change. I've updated the resolution. Bran, you can include the resolution in the next ballot. Tim > -----Original Message----- > From: Kenneth Hussey [mailto:khussey@ca.ibm.com] > Sent: Wednesday, August 17, 2005 10:35 PM > To: uml2rtf > Subject: RE: 8069: Draft version of PrimitiveType Real resolution > > > Tim, > > I believe all literal specifications are computable, so the > isComputable() query could perhaps be redefined to return > true in LiteralSpecification. All value specifications are > not null except for literal null, so either we would need to > keep LiteralNull or redefined isNull to be based on the value > of a property in LiteralSpecification. > > Yes, these other operation presume the existence of the > built-in literal types (the operations are redefined in each > subtype to return the appropriate result). I believe that > adding a realValue() operation would defeat your purpose, so > perhaps these additional (type-specific) operations need to > be removed. I am concerned, however, what impact this may > have have on existing tools... > > Cheers, > > Kenn Hussey > > Eclipse UML2 Project Lead > Rational Software, IBM Software Group