Issue 6616: UML Superstructure FTF : isRoot property disappeared (uml2-rtf) Source: (Dr. Guus Ramackers, Guus.Ramackers(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: The property isRoot has disappeared from Classifier. INtention was to move it to RedefinableElement but it seems to have dropped through the cracks. On page 399 FAS: section 13.3.4 The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement. On page 86 FAS section 7.8.3 RedefinableElement: isLeaf: Boolean Indicates whether it is possible to further specialize a RedefinableElement. If the value is true, then it is not possible to further specialize the RedefinableElement. Default value is false. But no mention of isRoot.... Resolution: Discussion This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification. Disposition: Closed - No Change Revised Text: Actions taken: November 14, 2003: received issue February 20, 2015: closed issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== te: Fri, 14 Nov 2003 15:47:41 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: issues@omg.org Subject: UML Superstructure FTF : isRoot property disappeared The property isRoot has disappeared from Classifier. INtention was to move it to RedefinableElement but it seems to have dropped through the cracks. On page 399 FAS: section 13.3.4 The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement. On page 86 FAS section 7.8.3 RedefinableElement: isLeaf: Boolean Indicates whether it is possible to further specialize a RedefinableElement. If the value is true, then it is not possible to further specialize the RedefinableElement. Default value is false. But no mention of isRoot.... -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Subject: RE: Super FTF telecon on Wed. Aug. 18 Date: Tue, 17 Aug 2004 16:43:42 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Super FTF telecon on Wed. Aug. 18 Thread-Index: AcSEqTAaQMluTGe6QmefADO1NI9UZAAB1OVQ From: "Karl Frank" To: "Branislav Selic" Cc: , X-OriginalArrivalTime: 17 Aug 2004 23:43:43.0973 (UTC) FILETIME=[08329950:01C484B4] 1. 6212 It may be yet another defect if having a query named "isCoConsistentWith" is incompatible with queries of another name defined in another place "isConsistentWith()" . The prepended "co" is supposed to suggest "covariance" as opposed to "contra" in contravariance. Questions: -- argumentative in intent but meant in a collaborative way, my intent is to get a good spec out of this, not win arguments -- a) How can the "same" query be defined in more than one place?. You say "the query is defined in numerous places in the spec". The same query or queries of the same name? If the name is "isConsistentWith", how is that query inconsistent with one named "isCoConsistentWith" ? b) Isn't it a problem to have the word "consistent" used in a way contrary to its accepted meaning OUTSIDE the spec? For Operations, the definition as it stands in the spec is most certainly not what the words "is consistent with " mean. These words have a longer history by orders of magnitude than the few decades computers have been around. c) For us who are used to naming conventions, and have stomached using the word redefinition to include renaming, why is a made up word like "coconsistent" such a problem? 2. 6404 Given that a resolution to 6404 is in ballot 23, we should surely pull it from Ballot 24. You just sent me a list in which you listed 6405 as one of my remaining 10 issues and I screwed up by pulling 6404. Sorry.. 3. 6437. I always forget about Infra, since I am not on the Infra FTF. Will research the infra implications. 4. 6616 I specifically called Guus' attention to this already in the email you received, don't understand why you should suggest what I have already told you I did. Guus' views on the matter will get good attention, I am sure. But if he wants "isRoot" back (the issue does NOT say it is needed, nor does it give any argument for why it's loss is regrettable) he should explain why, because it is easier to leave it out. It is not in the FAS as approved, and no-one (including Guus) has so far given any complaint. 5. 7400. Yes, the terminology should be "Closed, no change". I had to create my own format for these, reliving the hell you have been thru often enough, because the styles and wording on the issues website do not match our report styles and wording, and I got this wrong. Will change it for the ballot. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 6:26 PM To: Karl Frank Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Super FTF telecon on Wed. Aug. 18 Karl, some feedback on your propsoed resolutions: 6212: I have two objections to your resolution: (1) I do not feel that renaming "isConsistentWith()" to "isCoConsistentWith()" improves anything as the concept of "co-consistency" is not a common and well-understood term in the computing science community and (2), that query is defined in numerous places in the spec and would have to be redefined everywhere. I would much prefer your second potential solution. 6404: I have already provided a resolution to this issue in ballot 23. (Also, I think that your resolution is incorrect.) 6437: shouldn't this also have an Infrastructure fix in it? 6630: We had this discussion already and I strongly object to your resolution. Specifically, I believe that a client of a dependency should be able to navigate to its dependencies (it is the client). The ramifications of your change are significant since Dependency is the parent class of Realization, Usage, and InterfaceRealization, which are extensively used in many models. Your resolution will impact many implementations adversely. 6616: I seem to recall that Guus felt rather strongly about this one. I suggest that you consult him about it directly. 7400: shouldn't this be a "closed, no change" rather than a "resolved"? Cheers, Bran "Karl Frank" 08/17/2004 03:53 PM To Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject RE: Super FTF telecon on Wed. Aug. 18 Eight proposals are attached. One, 6630, met with counterarguments in an earlier circulation. I am still convinced my proposal is in the best interest of UML modeling, so I am sending it out again with a little more argument to back it up. The obvious easy resolution is self-evident, just x-out the navigability from Supplier, but before I fall back to that easy answer, I want to try out my preferred solution first. Guus, one of your issues is in this batch, so you should look for it. 6616, humorously but accurately named "isRoot disappeared". Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 3:20 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Super FTF telecon on Wed. Aug. 18 DATE: Wed. Aug. 18 TIME: 11 am EDT (usual time) DURATION: 35 minutes NUMBER: 866 842-3549 (toll free North America) 1+613 787-5018 (International) PASSCODE: 8455752# Please plan to attend this one, it is very important. Thanks...Bran[attachment "ForBallot24.doc" deleted by Branislav Selic/Ottawa/IBM] To: "Karl Frank" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Super FTF telecon on Wed. Aug. 18 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 17 Aug 2004 20:32:01 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/17/2004 20:32:02, Serialize complete at 08/17/2004 20:32:02 Karl, A few additional comments embedded below: > 1. 6212 It may be yet another defect if having a query named > "isCoConsistentWith" is incompatible with queries of another name > defined in another place "isConsistentWith()" . > The prepended "co" > is supposed to suggest "covariance" as opposed to "contra" in > contravariance. > Questions: -- argumentative in intent but meant in a collaborative > way, my intent is to get a good spec out of this, not win arguments -- > a) How can the "same" query be defined in more than one place?. You > say "the query is defined in numerous places in the spec". The same > query or queries of the same name? If the name is > "isConsistentWith", how is that query inconsistent with one named > "isCoConsistentWith" ? This was by intent. Since "consistency" has different meanings in different contexts and is also a semantic variation point, there is a default version (the one that you renamed) that was intended to be overridden by other more specific versions. So, a change in one place would require the thing to be changed in all the places. > b) Isn't it a problem to have the word "consistent" used in a way > contrary to its accepted meaning OUTSIDE the spec? For Operations, > the definition as it stands in the spec is most certainly not what > the words "is consistent with " mean. These words have a longer > history by orders of magnitude than the few decades computers have > been around. > c) For us who are used to naming conventions, and have stomached > using the word redefinition to include renaming, why is a made up > word like "coconsistent" such a problem? Perhaps you are used to it, but I am not and I honestly don't believe that most people would get any additional information out of it. In fact, I suspect that it will actually raise more questions. That is, while most people have an intuitive understanding of "consitent", I doubt if they have an intuition about what "co-consistent" could mean. > 2. 6404 Given that a resolution to 6404 is in ballot 23, we should > surely pull it from Ballot 24. You just sent me a list in which you > listed 6405 as one of my remaining 10 issues and I screwed up by > pulling 6404. Sorry.. No problem. > 3. 6437. I always forget about Infra, since I am not on the Infra > FTF. Will research the infra implications. OK > 4. 6616 I specifically called Guus' attention to this already in > the email you received, don't understand why you should suggest what > I have already told you I did. Guus' views on the matter will get > good attention, I am sure. But if he wants "isRoot" back (the issue > does NOT say it is needed, nor does it give any argument for why > it's loss is regrettable) he should explain why, because it is > easier to leave it out. It is not in the FAS as approved, and no- > one (including Guus) has so far given any complaint. Sorry. I now recall that you did draw Guus' attention to it. So, this is good. I agree with your proposed resolution, but wanted to make sure that it went into the ballot without being contested. > 5. 7400. Yes, the terminology should be "Closed, no change". I had > to create my own format for these, reliving the hell you have been > thru often enough, because the styles and wording on the issues > website do not match our report styles and wording, and I got this > wrong. Will change it for the ballot. No problem. You should be able to get the correct styles if you use the posted Draft FTF report. (And, you are right: I had to manually change the formatting of each and every paragraph of the 890 issues that are in that report.) Regards...Bran Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 02:22:18 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGUaOOvWEvXmwvTEeA2cPkA+ZL9gAHR9rg Priority: Urgent From: "Pete Rivett" To: "Branislav Selic" , , X-Virus-Scanned: by amavisd-new at sentraliant.com 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 04:54:15 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGUaOOvWEvXmwvTEeA2cPkA+ZL9gAHR9rgAA6L76A= From: "Karl Frank" To: "Pete Rivett" , "Branislav Selic" , , X-OriginalArrivalTime: 20 Aug 2004 11:54:17.0929 (UTC) FILETIME=[6C18FB90:01C486AC] wrt the ones I wrote up: 1. 6616 Right. More dyslexia than typo, the reversal of parent and child in 6616, will change. 2. 6171. Thomas made the same point. Agreed. 3. 6630: I agree with you on this, but removed the navigability supported by association ownership from my proposal because Conrad objected to it, and because I felt the new dot navigability notation would then constitute a quite different sort of change than the original issue was asking for. Then I thought, well if a product supports a where-used query which the spec does not require, this does not constitute non-compliance, it is a case of going beyond what is required. As you can see, I am in favor especially of providing for the dot notation (in my opinion a square dot would be better becauase of the ball end of IDEF/1 notation) but see it as a distinct issue. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 20, 2004 2:22 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Ballot 24 draft Importance: High 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran To: "Karl Frank" Cc: mu2i-ftf@omg.org, "Pete Rivett" , uml2-superstructure-ftf@omg.org Subject: RE: Ballot 24 draft X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 20 Aug 2004 08:28:03 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/20/2004 08:28:05, Serialize complete at 08/20/2004 08:28:05 I agree with Karl that introducing the dot notation at this point may not be appropriate since I think the issue needs more discussion. It really should have been introduced when ownership and navigability were separated. We may have to defer this to an RTF. Bran "Karl Frank" 08/20/2004 07:54 AM To "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject RE: Ballot 24 draft wrt the ones I wrote up: 1. 6616 Right. More dyslexia than typo, the reversal of parent and child in 6616, will change. 2. 6171. Thomas made the same point. Agreed. 3. 6630: I agree with you on this, but removed the navigability supported by association ownership from my proposal because Conrad objected to it, and because I felt the new dot navigability notation would then constitute a quite different sort of change than the original issue was asking for. Then I thought, well if a product supports a where-used query which the spec does not require, this does not constitute non-compliance, it is a case of going beyond what is required. As you can see, I am in favor especially of providing for the dot notation (in my opinion a square dot would be better becauase of the ball end of IDEF/1 notation) but see it as a distinct issue. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 20, 2004 2:22 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Ballot 24 draft Importance: High 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran Reply-To: From: "Conrad Bock" To: , Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 13:04:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Comments on ballot 24 below. Conrad - 4932 (Starting state machine) Typo: replace "filter" with "filer". - 5979 (The description of DataType is plainly wrong in the specification) Typo: "considered the be the same". I assume the Figure 41 example will be included in the final document, even though it isn't in the resolution? The removal of presentation options and style guidelines is a separate issue isn't it? - 6171 (Operation) The new text should refer to Generalization::isSubstitutable, rather than say issues of substitutability are out of scope. - 6616 (UML Superstructure FTF : isRoot property disappeared) The resolution says that isRoot can be derived from whether a classifier has supertypes. This is incorrect, because isRoot is a record for modeler intent that no supertypes will be defined for the classifier. It is analogous to isLeaf, which declares there will be no subtypes, so compilers can optimize message passing into function invocation. I don't mind that isRoot was removed, but the issue should not say it is derivable. - 6902 (Identify sections specifying run-time semantics) Thanks for the update on this. Combined with Jim R's much improved description of events in common behavior, this will be OK for process modelers. (Since the separation of inter- and intra-object is not reflected much in actions and behaviors, it still seems a little confusing, but we don't have time for another update). Typo: "TThese". - 6975 (missing illustrations of graphical paths for create and destroy message) The issues asks for examples, not new notation. That seems reasonable, so this one can be deferred. - 7219 (Operations and derived attributes) One of the roles of FTF/RTF's is to answer questions, even if there is no change. If there is not time to answer these, they can be deferred. - 7438 (Section: 12.3.3) The resolution is incorrect (this should have been assigned to Activities). Here is the resolution: "Connectors are purely notational and have no name. The name displayed is the name of the edge. This is stated by the first sentence under Figure 207. However, there may be an issue that edges are not contained by ownedMember, to be restricted by the Activity namespace, but this requires more discussion to resolve." Reply-To: Joaquin Miller X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Apr 2005 11:15:55 -0700 To: UML-RTF From: Joaquin Miller Subject: Ballot 1 draft Please review the proposed ballot 1 resolutions. I sent out a batch yesterday and others will, presumably, send some out later today and tomorrow. If you have any problems with any of the resolutions, this is the time to raise them, not when the ballot has been issued and the vote started. Issue 6275 This would have been clearer had there been an explicit {redefines raisedException} constraint on Operations::raisedException, so let's add that. Or, let's make explicit the reasonable policy that we have limited resources, so we will fix actual errors but not work to improve usability. Issue 6616 The isLeaf feature seems unnecessary, since it is easy to determine if something is a leaf classifier simply by checking whether it is included in the .generalization. meta-attribute of any classifier. In contrast, the .isRoot. property, on the other hand is necessary since it defines a constraint that defines that a classifier must not have any further generalizations. Or is it our intention that UML 2 does not have the capability to specify that the authors of a model intend that users are not to generalize from certain classifiers? Or, perhaps, is it explicit or implicit or assumed in the UML 2 specification that users can't or won't generalize existing classifiers, but that they can and will specialize existing classifiers? Issue 8075 Our audience includes readers of paper documents. If this happens only in a few places, let's correct this usability problem. If it is our policy to cater only to readers using Acrobat or Acrobat Reader, well... Maybe it is too late to change that policy. Issue 8082 Does the proposed resolution describe a best practice? Wouldn't the spec shine even more brightly if it stuck to a single style, even in examples? This is a pedagogical question, and very much worth our time to consider. Issues 8081, 8085, and 6502 I don't want to make work, but do have a question: Is there a positive reason to use integer instead of unlimited natural in the specification of lower bound, and then backpedal with a constraint? (I bet there is a positive reason not to use unlimited natural, and a good one; but then let's mention that reason in the resolution. If we had more resources, i'd urge adding natural to our armamentarium. ) Cordially, Joaquin www.joaquin.net Reply-To: From: "Conrad Bock" To: Subject: RE: Bran's proposed resolutions for ballot 1 Date: Sun, 10 Apr 2005 18:13:43 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Comments on your ballot 1 resolutions. Conrad - 6616 isRoot property disappeared If isLeaf constrains future specializations, isRoot could constrain future generalization. The filer is right that it is currently inconsistent. My understanding is these are used to tell whether dispatches can be compiled away. I think these kind of things are out of scope for UML, but if we have one, we should have the other. - 8075 search for referenced item The suggestion only works for readers of electronic format. The