Issue 6541: Exception of strict evaluation (=) (ocl2-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Author: Thomas Baar (thomas.baar@epfl.ch) Description: contradiction for evaluation of navigation expression Rationale: Suppose to have two classes A, B and an association with multiplicity 0..1 on B between them. The invariant context A inv: self.b = self.b is evaluated for an instance of A not having an associated instance of B to i) true, when the expression self.b has the type Set(B), because self.b is evaluated to emptyset and emptyset = emptyset is evaluated to true ii) undef, when the expression self.b has the type B, because self.b is evaluated to undef and undef = undef is evaluated to undef thanks to strict evaluation of '=' This is a contradiction since the expression self.b can be both of type set(B) and B! The examples also shows, that x = x is not a tautology unlike in almost all other logics including classical predicates logic. This is especially confusing because OCL claims to be based on classical predical logic! Resolution: Revised Text: Actions taken: November 10, 2003: received issue Discussion: Deferred for timing reasons End of Annotations:===== ption of strict evaluation (=) Author: Thomas Baar (thomas.baar@epfl.ch) Description: contradiction for evaluation of navigation expression Rationale: Suppose to have two classes A, B and an association with multiplicity 0..1 on B between them. The invariant context A inv: self.b = self.b is evaluated for an instance of A not having an associated instance of B to i) true, when the expression self.b has the type Set(B), because self.b is evaluated to emptyset and emptyset = emptyset is evaluated to true ii) undef, when the expression self.b has the type B, because self.b is evaluated to undef and undef = undef is evaluated to undef thanks to strict evaluation of '=' This is a contradiction since the expression self.b can be both of type set(B) and B! The examples also shows, that x = x is not a tautology unlike in almost all other logics including classical predicates logic. This is especially confusing because OCL claims to be based on classical predical logic! Subject: withdraw 6451 please Date: Fri, 30 Jul 2004 12:10:09 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: withdraw 6451 please Thread-Index: AcR2EL8h7zoOAKTsQnSb8VrlUgIhmwAVwffg From: "Karl Frank" To: "Branislav Selic" , , X-OriginalArrivalTime: 30 Jul 2004 19:10:10.0615 (UTC) FILETIME=[D5A36C70:01C47668] When I wrote up 6541 I was not aware that association lines with no arrowheads were navigable in all directions. Then in discussion the need for a notation to indicate a navigable end owned by the Association (and not by the Classifier at that end of the line) was suggesed. Subsequent discussion is beginning to point to a consensus on 6451, in connection with an explicit statement of navigation and ownership notations. Let's withdraw 6541 from Ballot 21 and revise it for Ballot 22. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, 29 July, 2004 7:02 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Draft of ballot 21 -- please review and provide feedback if you have it It's been hard to keep track of who has proposed what for ballot 21. So, it is likely that this draft may have some omissions or, possibly, outdated versions of the many resolutions that have been flying about. Please do have a good look at it -- there are only 12 resolutions on the ballot (slim pickings this time around!). Thanks, Bran Subject: Preparing 2nd ballot: Discussion regarding some other issues Date: Thu, 19 May 2005 19:34:42 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preparing 2nd ballot: Discussion regarding some other issues Thread-Index: AcVcmQqSPJdP6R9nRLWNyrXiTmRKBw== From: "BELAUNDE Mariano RD-MAPS-LAN" To: Cc: "Jos Warmer" , X-OriginalArrivalTime: 19 May 2005 17:34:43.0877 (UTC) FILETIME=[0B454D50:01C55C99] Hi all, Below my comments and questions regarding some other issues that could be solved during second ballot. I will appreciate any contribution to solve this set of issues. 1) Issue 3513: Usage of qualifiers. This is an OCL1 issue that seems already be solved by OCL 2. Jos, since you are the author of this issue, could you check this and if possible send to me a resolution text? 2) Issue 4121 : Grammar for OCL. Internalization issue. Solved by OCL2 since is left intentionally undefined by the spec. 3) Issue 4451: Downcast OCL collection operators. My first impression is that the request is pertinent and can be easy solved by adding the missing operations to the Collection type in the standard library. Any opinion? Is there any volunteer to propose a resolution text? 4) Issue 5970: flatten I agree with Jos comments that two operations are needed (deepFlatten and flatten). Is there any volunteer for proposing the resolution text?. 5) Issue 5971: OrderedSet My feeling is that this issue has to be Deferred to the RTF because for timing reasons it will be very difficult to update in the FTF, in a consistent way, the semantics chapter. Unless someone's wants to take the issue ... 6) Issue 5973: what is a collection? Seems like the issue request for a mechanism to treat a user-defined class as a collection. Is there any opinion regarding the disposition for this issue? 7) Issue 6534: Up-and-down-casts with oclAsType() I don't understand the text of this issue. Has someone an idea what is the point here? (there is no 2.4.6 in the ptc document). 8) Issue 6535: Lack of operation specifications Unless someone is interrested to take this, I propose to defer it to the RTF (for timing reasons).. 9) Issue 6538: Exception of strict evaluation (implies) Unless someone is interrested to take this, I propose to defer it to the RTF (for timing reasons).. 10) Issue 6539: Exception of strict evaluation (forAll,exists) Unless someone is interrested to take this, I propose to defer it to the RTF (for timing reasons).. 11) Issue 6540: Exception of strict evaluation (queries) Unless someone is interrested to take this, I propose to defer it to the RTF (for timing reasons).. 12) Issue 6541: Exception of strict evaluation (=) Unless someone is interrested to take this, I propose to defer it to the RTF (for timing reasons).. Regards, Mariano