Issue 8031: Destruction semantics in StructuredClassifier (uml2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Minor Summary: Destruction semantics in StructuredClassifier The destruction semantics in StructuredClassifier should include destruction of links created due to connectors between noncomposite properties Resolution: see above Revised Text: In section 9.3.6. "Connector", subsection "Semantics", replace the last sentence of the 2nd paragraph by: "All such links corresponding to connectors are destroyed, when the containing classifier instance is destroyed." Actions taken: December 30, 2004: received issue August 23, 2006: closed issue Discussion: After further discussions with Conrad, proposing enhancements to the text on p.171 along the lines suggested by Conrad: In section 9.3.6. "Connector", subsection "Semantics", replace the last sentence of the 2nd paragraph by: "All such links corresponding to connectors are destroyed, when the containing classifier instance is destroyed." This reflects Conrad's phrasing "all links that exist only because of connectors between roles of the structured classifier". However, I use "corresponding to connectors" to match the sentence before, where we talk about the creation of links corresponding to connectors. The connectors being destroyed are precisely those connectors that we speak about in the previous sentence. I think this is clearer. End of Annotations:===== m: webmaster@omg.org Date: 30 Dec 2004 15:28:12 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: No Specification: UML 2 Super Section: Composite FormalNumber: ptc/04-10-02 Version: 2.0 RevisionDate: 04-10-02 Page: - Nature: Revision Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description Destruction semantics in StructuredClassifier The destruction semantics in StructuredClassifier should include destruction of links created due to connectors between noncomposite properties. Reply-To: From: "Conrad Bock" To: "uml2rtf" Subject: Issues 8031, 8032 Date: Tue, 21 Jun 2005 08:39:45 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Composers, See attached proposals for issues 8031 and 8032, and on wiki at: http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000024 http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000025 Summary: Issue 8031 is modified from the original to not destroy links that shouldn't be. Issue 8032 is written in a more minimalist way than I would have liked, but hopefully more acceptable to Thomas. Conrad issueresolution-8031-8032.doc Subject: RE: Issues 8031, 8032 Date: Tue, 21 Jun 2005 14:08:23 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 8031, 8032 Thread-Index: AcV2Y8Ht7iCbXMNFTsGUj4ot3lQgAwAQUe0g From: "Mellor, Stephen" To: , "uml2rtf" X-OriginalArrivalTime: 21 Jun 2005 21:09:32.0098 (UTC) FILETIME=[84E18220:01C576A5] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5LLJXhh012001 I continue to disagree strongly with both these resolutions. They both--as I read them--take away from the primitive nature of the actions. There are multiple situations in which the automatic deletion of objects/links is not the right thing to do. I can explain why if you insist, but I have done so already several times over. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 2005-06-21, Tuesday 05:40 > To: uml2rtf > Subject: Issues 8031, 8032 > > Composers, > > See attached proposals for issues 8031 and 8032, and on wiki at: > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000024 > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000025 > > Summary: > > Issue 8031 is modified from the original to not destroy links that > shouldn't be. > > Issue 8032 is written in a more minimalist way than I would have > liked, but hopefully more acceptable to Thomas. > > Conrad > From: "Thomas Weigert" To: "'Mellor, Stephen'" , , "'uml2rtf'" Subject: RE: Issues 8031, 8032 Date: Wed, 22 Jun 2005 00:15:43 +0200 X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5LMPYhh012497 Stephen, Please remember that the UML is not constructed from action primitives. They are just there to define the detail of certain behaviors where needed. However, there is an object creation semantics that is completely independent of the actions. What these issues (which were submitted by Conrad) point out is that there are some improvements one could do to the formulation of some of those behaviors. We don't need to fix them, as far as I am concerned. But you will not make the fact go away that the actions are not fundamental to the UML, by resisting to fixing these issues. Cheers, Th. > -----Original Message----- > From: Mellor, Stephen [mailto:Stephen_Mellor@mentor.com] > Sent: Tuesday, June 21, 2005 11:08 PM > To: conrad.bock@nist.gov; uml2rtf > Subject: RE: Issues 8031, 8032 > > > I continue to disagree strongly with both these resolutions. They > both--as I read them--take away from the primitive nature of the > actions. There are multiple situations in which the automatic deletion > of objects/links is not the right thing to do. I can explain > why if you > insist, but I have done so already several times over. > > > -----Original Message----- > > From: Conrad Bock [mailto:conrad.bock@nist.gov] > > Sent: 2005-06-21, Tuesday 05:40 > > To: uml2rtf > > Subject: Issues 8031, 8032 > > > > Composers, > > > > See attached proposals for issues 8031 and 8032, and on wiki at: > > > > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > > 1000000024 > > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > > 1000000025 > > > > Summary: > > > > Issue 8031 is modified from the original to not destroy links that > > shouldn't be. > > > > Issue 8032 is written in a more minimalist way than I would have > > liked, but hopefully more acceptable to Thomas. > > > > Conrad > > > To: "Mellor, Stephen" Cc: conrad.bock@nist.gov, "uml2rtf" Subject: RE: Issues 8031, 8032 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 24 Jun 2005 02:49:34 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 06/24/2005 02:49:40, Serialize complete at 06/24/2005 02:49:40 Steve, Please note that these are really just the semantics of classifier properties that we are talking about: when an instance of a class is destroyed its structural features are removed along with it. So, the resolutions are merely repeating these semantics for the special case of links owned by a structured class. However, your comment and the proposed resolution helped me notice that we do have a problem in the original formulation when it says: "All instances corresponding to parts of a structured classifier are destroyed recursively,..." This is really the statement that you are objecting to I believe and I have a problem with it as well. This statement must be removed. While the you definitely destroy the slot in which part instances are contained, it should not necessarily mean that the instances themselves are destroyed. For example, in one of our products, object instances are merely "imported" (at run-time) into slots. This means that the objects are owned by some other container, but are temporarily "guests" inside the structured classifier instance. When the latter is destroyed, these parts are not. So, the only part instances that should be destroyed are those that are actually owned by the container. This is easily fixed by saying: "All instances corresponding to parts of a structured classifier that are owned by the instance of the structured classifier are destroyed recursively,..." I would still include Conrad's clarification on links, which I believe is valid. Regards, 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 "Mellor, Stephen" 06/21/2005 05:08 PM To , "uml2rtf" cc Subject RE: Issues 8031, 8032 I continue to disagree strongly with both these resolutions. They both--as I read them--take away from the primitive nature of the actions. There are multiple situations in which the automatic deletion of objects/links is not the right thing to do. I can explain why if you insist, but I have done so already several times over. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 2005-06-21, Tuesday 05:40 > To: uml2rtf > Subject: Issues 8031, 8032 > > Composers, > > See attached proposals for issues 8031 and 8032, and on wiki at: > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000024 > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000025 > > Summary: > > Issue 8031 is modified from the original to not destroy links that > shouldn't be. > > Issue 8032 is written in a more minimalist way than I would have > liked, but hopefully more acceptable to Thomas. > > Conrad > Reply-To: From: "Thomas Weigert" To: "'Branislav Selic'" , "'Mellor, Stephen'" Cc: , "'uml2rtf'" Date: Fri, 24 Jun 2005 09:43:46 +0200 X-Mailer: Microsoft Outlook, Build 10.0.6626 Subject: RE: Issues 8031, 8032 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on mail-mx1.hia.no X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=HTML_40_50,HTML_MESSAGE, HTML_TAG_EXIST_TBODY autolearn=no version=3.0.2 Bran, your clarification is what was intended and it improves readability... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, June 24, 2005 8:50 AM To: Mellor, Stephen Cc: conrad.bock@nist.gov; uml2rtf Subject: RE: Issues 8031, 8032 Steve, Please note that these are really just the semantics of classifier properties that we are talking about: when an instance of a class is destroyed its structural features are removed along with it. So, the resolutions are merely repeating these semantics for the special case of links owned by a structured class. However, your comment and the proposed resolution helped me notice that we do have a problem in the original formulation when it says: "All instances corresponding to parts of a structured classifier are destroyed recursively,..." This is really the statement that you are objecting to I believe and I have a problem with it as well. This statement must be removed. While the you definitely destroy the slot in which part instances are contained, it should not necessarily mean that the instances themselves are destroyed. For example, in one of our products, object instances are merely "imported" (at run-time) into slots. This means that the objects are owned by some other container, but are temporarily "guests" inside the structured classifier instance. When the latter is destroyed, these parts are not. So, the only part instances that should be destroyed are those that are actually owned by the container. This is easily fixed by saying: "All instances corresponding to parts of a structured classifier that are owned by the instance of the structured classifier are destroyed recursively,..." I would still include Conrad's clarification on links, which I believe is valid. Regards, 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 "Mellor, Stephen" 06/21/2005 05:08 PM To , "uml2rtf" cc Subject RE: Issues 8031, 8032 I continue to disagree strongly with both these resolutions. They both--as I read them--take away from the primitive nature of the actions. There are multiple situations in which the automatic deletion of objects/links is not the right thing to do. I can explain why if you insist, but I have done so already several times over. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 2005-06-21, Tuesday 05:40 > To: uml2rtf > Subject: Issues 8031, 8032 > > Composers, > > See attached proposals for issues 8031 and 8032, and on wiki at: > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000024 > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000025 > > Summary: > > Issue 8031 is modified from the original to not destroy links that > shouldn't be. > > Issue 8032 is written in a more minimalist way than I would have > liked, but hopefully more acceptable to Thomas. > > Conrad > Subject: RE: Issues 8031, 8032 Date: Fri, 24 Jun 2005 13:15:30 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 8031, 8032 Thread-Index: AcV4iOe48mAWnuF1RQCv/AxU/P8H8QAR0/lg From: "Mellor, Stephen" To: "Branislav Selic" Cc: , "uml2rtf" X-OriginalArrivalTime: 24 Jun 2005 20:15:31.0467 (UTC) FILETIME=[788DB5B0:01C578F9] OK. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 2005-06-23, Thursday 23:50 To: Mellor, Stephen Cc: conrad.bock@nist.gov; uml2rtf Subject: RE: Issues 8031, 8032 Steve, Please note that these are really just the semantics of classifier properties that we are talking about: when an instance of a class is destroyed its structural features are removed along with it. So, the resolutions are merely repeating these semantics for the special case of links owned by a structured class. However, your comment and the proposed resolution helped me notice that we do have a problem in the original formulation when it says: "All instances corresponding to parts of a structured classifier are destroyed recursively,..." This is really the statement that you are objecting to I believe and I have a problem with it as well. This statement must be removed. While the you definitely destroy the slot in which part instances are contained, it should not necessarily mean that the instances themselves are destroyed. For example, in one of our products, object instances are merely "imported" (at run-time) into slots. This means that the objects are owned by some other container, but are temporarily "guests" inside the structured classifier instance. When the latter is destroyed, these parts are not. So, the only part instances that should be destroyed are those that are actually owned by the container. This is easily fixed by saying: "All instances corresponding to parts of a structured classifier that are owned by the instance of the structured classifier are destroyed recursively,..." I would still include Conrad's clarification on links, which I believe is valid. Regards, 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 "Mellor, Stephen" 06/21/2005 05:08 PM To , "uml2rtf" cc Subject RE: Issues 8031, 8032 I continue to disagree strongly with both these resolutions. They both--as I read them--take away from the primitive nature of the actions. There are multiple situations in which the automatic deletion of objects/links is not the right thing to do. I can explain why if you insist, but I have done so already several times over. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 2005-06-21, Tuesday 05:40 > To: uml2rtf > Subject: Issues 8031, 8032 > > Composers, > > See attached proposals for issues 8031 and 8032, and on wiki at: > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000024 > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000025 > > Summary: > > Issue 8031 is modified from the original to not destroy links that > shouldn't be. > > Issue 8032 is written in a more minimalist way than I would have > liked, but hopefully more acceptable to Thomas. > > Conrad > Reply-To: From: "Conrad Bock" To: "'uml2rtf'" Cc: Subject: RE: Issues 8031, 8032 Date: Tue, 28 Jun 2005 11:35:53 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Sorry if this is duplicated. Steve, et al, > I continue to disagree strongly with both these resolutions. They > both--as I read them--take away from the primitive nature of the > actions. There are multiple situations in which the automatic deletion > of objects/links is not the right thing to do. I can explain why if you > insist, but I have done so already several times over. Perhaps the wording needs to be changed then, but my intention was to preserve the primitiveness of actions, while defining the semantics composite structure around link deletion. The DestroyObjectActioin semantics is unaffected by these proposals (which intentionally do not refer to the actions directly). > [Bran] However, your comment and the proposed resolution helped me > notice that we do have a problem in the original formulation when it > says: > > "All instances corresponding to parts of a structured classifier > are destroyed recursively,..." > > This is really the statement that you are objecting to I believe and > I have a problem with it as well. This statement must be > removed. While the you definitely destroy the slot in which part > instances are contained, it should not necessarily mean that the > instances themselves are destroyed. For example, in one of our > products, object instances are merely "imported" (at run-time) into > slots. This means that the objects are owned by some other container, > but are temporarily "guests" inside the structured classifier > instance. When the latter is destroyed, these parts are not. I took "part" above in the technical sense it is defined in the composites chapter, namely, strong composition properties (see Figure 95, > So, the only part instances that should be destroyed are those > that are actually owned by the container. This is easily fixed > by saying: > > "All instances corresponding to parts of a structured classifier > that are owned by the instance of the structured classifier are > destroyed recursively,..." We could clarify as above, but it is a different issue (8031 and 8032 are about link deletion). Would probably be a good idea, because the composites chapter often uses parts informally. Shall I file an issue? > [Thomas] What these issues (which were submitted by Conrad) point out > is that there are some improvements one could do to the formulation > of some of those behaviors. Thomas, shall we take the posted document as the Composite WG proposals for 8031, 8032 in ballot 6? Conrad Reply-To: From: "Conrad Bock" To: "uml2rtf" Subject: RE: Issues 8031, 8032, updated proposal Date: Tue, 5 Jul 2005 15:17:04 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, et al, Here's a small update to the 8031 proposal, from Guus' comment that links may exist due to other connectors in other composites not being destroyed, and these should not be destroyed. See beginning of quote in revised text, and end of discussion. The 8032 proposal is included for reference. The document is attached to both issues on the twiki. Do these look OK for ballot 6? Conrad Issue 8031: Destruction semantics in StructuredClassifier Issue summary Destruction semantics in Structured Classifier? The destruction semantics in Structured Classifier? should include destruction of links created due to connectors between noncomposite properties Discussion Removed discussion not pertaining to this issue (see here) I object to removing the pertinent dicussion. Included the jist of it below. If you don't want to address it in composite structure, I'd be glad to take the issue in the Composite WG, as you originally requested. The proposal sets up a semantic dependency of actions on composite structure. It also introduces an ambiguity into the semantics of actions, because the same model will execute differently depending on which semantic variation an implementor uses. -- ConradBock - 03 Jun 2005 Conrad, your discussion pertained to Issue 8032, not to this issue. Also, I requested that you handle the second half of 8032. Your comment above does not apply to this issue either.... -- ThomasWeigert - 04 Jun 2005 Revised Test In Section 9.3.13., subsection .Semantics., add after the first sentence of the paragraph preceding the .Semantic variation point. heading: .All links created based on connectors between roles of the structured classifier as well as links created using link actions are destroyed.. Resolution Reply-To: From: "Conrad Bock" To: "Branislav Selic" , Subject: RE: Second version of draft 5 ballot Date: Tue, 7 Jun 2005 09:15:28 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Here are my comments on draft ballot 5. Thomas, I checked for ballot 5 measures on the wiki on Friday and didn't see the ones included in draft ballot 5. Could the WG resolutions being discussed for proposal to the RTF be identified earlier? Conrad Issue 8027: Connector multiplicity notation The proposed replacement sentence in the notation of ConnectorEnd: "These adornments specify properties of the association typing the connector, if that association was inferred, or show properties of that association, otherwise." still refers only to the association in describing the semantics of the adornment, leaving out reference to specialization on the connector. The text that does this is currently in semantics section of Connector, along with other detail of what the adornment shows. Presumably this should be in the notation of ConnectorEnd. Issue 8031: Destruction semantics in StructuredClassifier I'd like this removed from the ballot for more discussion in the Reply-To: From: "Conrad Bock" To: "Branislav Selic" , Subject: RE: Second version of draft 5 ballot, update to comments Date: Wed, 8 Jun 2005 08:54:41 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Here's an update to my comments on draft ballot 5, in 8031. Thomas, I checked for ballot 5 measures on the wiki on Friday and didn't see the ones included in draft ballot 5. Could the WG resolutions being discussed for proposal to the RTF be identified earlier? Conrad Issue 8027: Connector multiplicity notation The proposed replacement sentence in the notation of ConnectorEnd: "These adornments specify properties of the association typing the connector, if that association was inferred, or show properties of that association, otherwise." still refers only to the association in describing the semantics of the adornment, leaving out reference to specialization on the connector. The text that does this is currently in semantics section of Connector, along with other detail of what the adornment shows. Presumably this should be in the notation of ConnectorEnd. Issue 8031: Destruction semantics in StructuredClassifier I'd like this removed from the ballot for more discussion in the RTF. It's all been external so far. In addition to that, the wording of the current proposal is too broad. It specifies deletion Reply-To: From: "Conrad Bock" To: "Branislav Selic" , Subject: RE: Second version of draft 5 ballot, update to comments Date: Wed, 8 Jun 2005 08:54:41 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Here's an update to my comments on draft ballot 5, in 8031. Thomas, I checked for ballot 5 measures on the wiki on Friday and didn't see the ones included in draft ballot 5. Could the WG resolutions being discussed for proposal to the RTF be identified earlier? Conrad Issue 8027: Connector multiplicity notation The proposed replacement sentence in the notation of ConnectorEnd: "These adornments specify properties of the association typing the connector, if that association was inferred, or show properties of that association, otherwise." still refers only to the association in describing the semantics of the adornment, leaving out reference to specialization on the connector. The text that does this is currently in semantics section of Connector, along with other detail of what the adornment shows. Presumably this should be in the notation of ConnectorEnd. Issue 8031: Destruction semantics in StructuredClassifier I'd like this removed from the ballot for more discussion in the RTF. It's all been external so far. In addition to that, the wording of the current proposal is too broad. It specifies deletion Subject: RE: Second version of draft 5 ballot, update to comments Date: Wed, 8 Jun 2005 16:59:59 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Second version of draft 5 ballot, update to comments Thread-Index: AcVsKdCLpeIHUPXwTIyD4HSf34nsAwAW/XPg From: "Mellor, Stephen" To: , "Branislav Selic" , X-OriginalArrivalTime: 09 Jun 2005 00:01:26.0937 (UTC) FILETIME=[61A24890:01C56C86] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5909phh015282 I have deep concerns about 8031 and, if I understand it correctly, 8032. They both attempt to build higher level operations on top of the action primitives. Fine and dandy--for an action language. Absolutely not for the metamodel! Conrad beat to me to it on 8031. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 2005-06-08, Wednesday 05:55 > To: Branislav Selic; uml2-rtf@omg.org > Subject: RE: Second version of draft 5 ballot, update to comments > > Bran, > > Here's an update to my comments on draft ballot 5, in 8031. > > > Thomas, > > I checked for ballot 5 measures on the wiki on Friday and > didn't see the > ones included in draft ballot 5. Could the WG resolutions being > discussed for proposal to the RTF be identified earlier? > > Conrad > > > > Issue 8027: Connector multiplicity notation > > The proposed replacement sentence in the notation of ConnectorEnd: > > "These adornments specify properties of the association > typing the > connector, if that association was inferred, or show properties > of that association, otherwise." > > still refers only to the association in describing the > semantics of > the adornment, leaving out reference to specialization on the > connector. The text that does this is currently in semantics > section of Connector, along with other detail of what the > adornment > shows. Presumably this should be in the notation of ConnectorEnd. > > > Issue 8031: Destruction semantics in StructuredClassifier > > I'd like this removed from the ballot for more discussion in the > RTF. It's all been external so far. In addition to that, the > wording of the current proposal is too broad. It > specifies deletion > of links that shouldn't be destroyed. > From: "Thomas Weigert" To: "'Mellor, Stephen'" , , "'Branislav Selic'" , Subject: RE: Second version of draft 5 ballot, update to comments Date: Wed, 8 Jun 2005 19:30:59 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j590dRhh015385 Stephen, this is already the case all over the UML, and also in this particular situation. The issue requests that this be better spelled out... As you know, the UML is a higher level language, and it is NOT built up from action primitives... Th. > -----Original Message----- > From: Mellor, Stephen [mailto:Stephen_Mellor@mentor.com] > Sent: Wednesday, June 08, 2005 7:00 PM > To: conrad.bock@nist.gov; Branislav Selic; uml2-rtf@omg.org > Subject: RE: Second version of draft 5 ballot, update to comments > > > I have deep concerns about 8031 and, if I understand it > correctly, 8032. > They both attempt to build higher level operations on top of > the action > primitives. Fine and dandy--for an action language. > Absolutely not for > the metamodel! > > Conrad beat to me to it on 8031. > > > -----Original Message----- > > From: Conrad Bock [mailto:conrad.bock@nist.gov] > > Sent: 2005-06-08, Wednesday 05:55 > > To: Branislav Selic; uml2-rtf@omg.org > > Subject: RE: Second version of draft 5 ballot, update to comments > > > > Bran, > > > > Here's an update to my comments on draft ballot 5, in 8031. > > > > > > Thomas, > > > > I checked for ballot 5 measures on the wiki on Friday and > > didn't see the > > ones included in draft ballot 5. Could the WG resolutions being > > discussed for proposal to the RTF be identified earlier? > > > > Conrad > > > > > > > > Issue 8027: Connector multiplicity notation > > > > The proposed replacement sentence in the notation of > ConnectorEnd: > > > > "These adornments specify properties of the association > > typing the > > connector, if that association was inferred, or show > properties > > of that association, otherwise." > > > > still refers only to the association in describing the > > semantics of > > the adornment, leaving out reference to specialization on the > > connector. The text that does this is currently in semantics > > section of Connector, along with other detail of what the > > adornment > > shows. Presumably this should be in the notation of > ConnectorEnd. > > > > > > Issue 8031: Destruction semantics in StructuredClassifier > > > > I'd like this removed from the ballot for more discussion in the > > RTF. It's all been external so far. In addition to that, the > > wording of the current proposal is too broad. It > > specifies deletion > > of links that shouldn't be destroyed. > > > Subject: Re: Second version of draft 5 ballot, update to comments Date: Wed, 8 Jun 2005 20:53:44 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Second version of draft 5 ballot, update to comments Thread-Index: AcVsioNCWccAG9prT2u5ML6tkdOa2AAHFGTv From: "Mellor, Stephen" To: , , , X-OriginalArrivalTime: 09 Jun 2005 03:53:45.0049 (UTC) FILETIME=[D5656490:01C56CA6] That wouuld precisely agianst the spirit of the action model -----Original Message----- From: Thomas Weigert To: Mellor, Stephen ; conrad.bock@nist.gov ; 'Branislav Selic' ; uml2-rtf@omg.org Sent: Wed Jun 08 17:30:59 2005 Subject: RE: Second version of draft 5 ballot, update to comments Stephen, this is already the case all over the UML, and also in this particular situation. The issue requests that this be better spelled out... As you know, the UML is a higher level language, and it is NOT built up from action primitives... Th. > -----Original Message----- > From: Mellor, Stephen [mailto:Stephen_Mellor@mentor.com] > Sent: Wednesday, June 08, 2005 7:00 PM > To: conrad.bock@nist.gov; Branislav Selic; uml2-rtf@omg.org > Subject: RE: Second version of draft 5 ballot, update to comments > > > I have deep concerns about 8031 and, if I understand it > correctly, 8032. > They both attempt to build higher level operations on top of > the action > primitives. Fine and dandy--for an action language. > Absolutely not for > the metamodel! > > Conrad beat to me to it on 8031. > > > -----Original Message----- > > From: Conrad Bock [mailto:conrad.bock@nist.gov] > > Sent: 2005-06-08, Wednesday 05:55 > > To: Branislav Selic; uml2-rtf@omg.org > > Subject: RE: Second version of draft 5 ballot, update to comments > > > > Bran, > > > > Here's an update to my comments on draft ballot 5, in 8031. > > > > > > Thomas, > > > > I checked for ballot 5 measures on the wiki on Friday and > > didn't see the > > ones included in draft ballot 5. Could the WG resolutions being > > discussed for proposal to the RTF be identified earlier? > > > > Conrad > > > > > > > > Issue 8027: Connector multiplicity notation > > > > The proposed replacement sentence in the notation of > ConnectorEnd: > > > > "These adornments specify properties of the association > > typing the > > connector, if that association was inferred, or show > properties > > of that association, otherwise." > > > > still refers only to the association in describing the > > semantics of > > the adornment, leaving out reference to specialization on the > > connector. The text that does this is currently in semantics > > section of Connector, along with other detail of what the > > adornment > > shows. Presumably this should be in the notation of > ConnectorEnd. > > > > > > Issue 8031: Destruction semantics in StructuredClassifier > > > > I'd like this removed from the ballot for more discussion in the > > RTF. It's all been external so far. In addition to that, the > > wording of the current proposal is too broad. It > > specifies deletion > > of links that shouldn't be destroyed. > > > From: "Thomas Weigert" To: "'Mellor, Stephen'" , , , Subject: RE: Second version of draft 5 ballot, update to comments Date: Wed, 8 Jun 2005 23:03:08 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 Well, it is a fact. If you read through the UML specification, there is many constructs that have semantics, in particular in the behavior and internal structure area. The actions are there to build up behavior to be assembled in activities, and they could be used from within other behaviors. Nevertheless, the actions need to be consistent with the macro-level semantics, in case they are able to emulate them. For example, the semantics of Class says that when an active class is created, its ClassifierBehavior is invoked. An action should not violate such (albeit counter to the spirit of UML the action semantics allows the creation of objects that are not following the above UML semantics, which is a defect. (If the action would be part of an underlying base language, that would be a different story.) There has been no attempt, and there are no plans, to explain the macro level behaviors in terms of underlying actions. So I am confused by your concern, as well as by your claim below... 8031 has nothing to do with actions. It clarifies the macro level semantics of the creation of structured objects. 8032 requests that actions are somehow integrated into that scheme. I am merely concerned about the macro semantics. The submitter of the issue (Conrad) has argued that the actions should be brought in also... I cannot see what objection one might have to the proposed resolution to 8031 but am willing to learn... Th. -----Original Message----- From: Mellor, Stephen [mailto:Stephen_Mellor@mentor.com] Sent: Wednesday, June 08, 2005 10:54 PM To: Thomas Weigert; conrad.bock@nist.gov; bselic@ca.ibm.com; uml2-rtf@omg.org Subject: Re: Second version of draft 5 ballot, update to comments That wouuld precisely agianst the spirit of the action model -----Original Message----- From: Thomas Weigert To: Mellor, Stephen ; conrad.bock@nist.gov ; 'Branislav Selic' ; uml2-rtf@omg.org Sent: Wed Jun 08 17:30:59 2005 Subject: RE: Second version of draft 5 ballot, update to comments Stephen, this is already the case all over the UML, and also in this particular situation. The issue requests that this be better spelled out... As you know, the UML is a higher level language, and it is NOT built up from action primitives... Th. > -----Original Message----- > From: Mellor, Stephen [mailto:Stephen_Mellor@mentor.com] > Sent: Wednesday, June 08, 2005 7:00 PM > To: conrad.bock@nist.gov; Branislav Selic; uml2-rtf@omg.org > Subject: RE: Second version of draft 5 ballot, update to comments > > > I have deep concerns about 8031 and, if I understand it > correctly, 8032. > They both attempt to build higher level operations on top of > the action > primitives. Fine and dandy--for an action language. > Absolutely not for > the metamodel! > > Conrad beat to me to it on 8031. > > > -----Original Message----- > > From: Conrad Bock [mailto:conrad.bock@nist.gov] > > Sent: 2005-06-08, Wednesday 05:55 > > To: Branislav Selic; uml2-rtf@omg.org > > Subject: RE: Second version of draft 5 ballot, update to comments > > > > Bran, > > > > Here's an update to my comments on draft ballot 5, in 8031. > > > > > > Thomas, > > > > I checked for ballot 5 measures on the wiki on Friday and > > didn't see the > > ones included in draft ballot 5. Could the WG resolutions being > > discussed for proposal to the RTF be identified earlier? > > > > Conrad > > > > > > > > Issue 8027: Connector multiplicity notation > > > > The proposed replacement sentence in the notation of > ConnectorEnd: > > > > "These adornments specify properties of the association > > typing the > > connector, if that association was inferred, or show > properties > > of that association, otherwise." > > > > still refers only to the association in describing the > > semantics of > > the adornment, leaving out reference to specialization on the > > connector. The text that does this is currently in semantics > > section of Connector, along with other detail of what the > > adornment > > shows. Presumably this should be in the notation of > ConnectorEnd. > > > > > > Issue 8031: Destruction semantics in StructuredClassifier > > > > I'd like this removed from the ballot for more discussion in the > > RTF. It's all been external so far. In addition to that, the > > wording of the current proposal is too broad. It > > specifies deletion > > of links that shouldn't be destroyed. > > > Subject: RE: Second version of draft 5 ballot Date: Fri, 10 Jun 2005 12:49:21 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Second version of draft 5 ballot Thread-Index: AcVqDi4LnbIGtvCzTnu2ZkZCe2GoggDuTiyQ Priority: Urgent From: "Pete Rivett" To: "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com See below. Quite a few comments but all minor except for issue 8449 which I think should be pulled. 7756 The heading 'Discussion' should be replaced by 'Revised Text'. The issue replaces several paragraphs so instead of "change the paragraph " should say "replace the following text". The corresponding text in Infra also needs updating. 7756: the English for the new text could be improved, and I think 'a usual class' is not clear. Also 'navigable' is used in the old sense not the new sense: I presume the intention is the old sense (that there is a property on the Stereotype) Here is suggested new text (my changes in red) Stereotypes can participate in associations. The opposite class can be another stereotype, a non-Stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the other class/metaclass. Issue 8031: I don't think the interaction between Conrad and Bran belongs in the discussion. See my proposed guidance in my vote on Ballot 4 (earlier today). Issue 8117: ditto. Issue 8187, 8239, 8262: Would be better to use the proper syntax to express the 'subsets' Issue 8225, 8262, others: Was it intentional to replace [0..*] by [*]? I thought the preferred style was the former. More generally, we seem to be spending a lot of cycles faffing around with issues related to * and 0..* - do people not realize that they are identical? Issue 8234: ditto Issue 8256: Use of 'at least' implies than more than one instance of stereotype may be attached to a single element. Suggested rewording: "If the extending stereotype has subclasses, then at one instance of the stereotype or one of its subclasses is required." Issue 8301: Should say 'increased clarity' not 'increased clarify'. Issue 8449: As I said in the discussion within the Profiles group I think Image should be a PrimitiveType. Even if Image is an instance of DataType rather than PrimitiveType the proposed resolution does not reflect this and in fact makes no sense as it stands since it is at the wrong metalevel: it would allow a Stereotype to refer, as an image to an actual datatype in the UML metamodel (or a user model) - for example 'Integer' or 'AddressType'! I will follow up with more detailed email but I think this issue must be pulled from ballot for now. Issue 8608: The Revised text says ", replace .intended. by the word .intended." - the first 'intended' should be 'intedded' The disposition should be 'Resolved' not 'closed no change' Issue 8619: I think a portion of the 'Discussion' could be added to clarify the diagram in Appendix F. I propose the following: Revised Text: Add the following to the end of the first (and only) paragraph in Appendix F The .classes. in this diagram that do not have superclasses are actually merge increments. Their superclasses can be inferred from any increment that actually has a superclass. Putting those in the diagram would not add any information but would simply clutter the diagram. Issue 8824: Did we not already address this in Ballot 4 with issue 8349 ( I have not checked the detail though)? 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: Sunday, June 05, 2005 9:17 PM To: uml2-rtf@omg.org Subject: Second version of draft 5 ballot I am having problems with my mailer that is having trouble sending larger files. It looks like my previous post of the ballot 5 draft did not get through. So, I'm sending this new ZIPPED version (however, to get around the OMG aversion to Zipped files, I have given it a "zap" suffix -- which you should change bck to "zip" when you receive the file.) For those who may have received the original version, this one is different in that it has added Tim Weilkins' fix to issue 8467. Bran Reply-To: From: "Conrad Bock" To: "uml2rtf" Subject: RE: Issues 8031, 8032, updated proposal 2 Date: Sun, 17 Jul 2005 10:55:14 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) (Discussion from wiki, posted here for the RTF) Hi Thomas, 8031: > Aren't "links between roles that are non-composite properties" > included in "all links"? Why does this need to be highlighted? Didn't follow this exactly, except I guess removing "All" doesn't change the meaning. See attached update. > Why should links created by link actions not be destroyed when the > classifier is destroyed? There may be many links between the instances playing the roles that were not created due to the connectors of the composite that is being destroyed. They might have been created by other composites not being destroyed, for example, or link actions of unrelated behaviors. These might be destroyed because the instance playing the role is destroyed, but that is a separate matter from the current issue. And of course some of the instances playing roles will not be destroyed, because the role is a noncomposite property. See discussion in atached proposal. 8032: > What does it mean to "no longer play a role". This does not appear > to be a defined term in the specification. It means "no longer a value of the role". Perhaps role should be replaced with "property"? See updated revised text, attached. Conrad issueresolution-8031-80323.doc Issue 8031: Destruction semantics in StructuredClassifier Click here for this issue's archive. Source: NIST (Mr. Conrad Bock, mailto:%20conrad.bock@nist.gov) Nature: Revision Severity: Minor Summary: Destruction semantics in StructuredClassifier The destruction semantics in StructuredClassifier should include destruction of links created due to connectors between noncomposite properties Resolution: Resolved Discussion: The original text proposed for this issue was: In Section 9.3.13., subsection .Semantics., add after the first sentence of the paragraph preceding the .Semantic variation point. heading: .All links created based on connectors between roles of the structured classifier as well as links created using link actions are destroyed.. It would have resulted in destruction of links between objects in non-composite properties that were not created based on connectors. It is not necessary to refer to links created by link actions not based on connectors, since these are destroyed when one of their end objects is destroyed, if desired, see DestroyObjectAction. The text below corrects this and clarifies that the destroyed links include those based on connectors even for roles that are non-composite. The wording excludes those links that may exist because of connectors in other composites that are not being destroyed. Revised Text: In Section 9.3.13., subsection .Semantics., add after the first sentence of the paragraph preceding the .Semantic variation point. heading: .Links created that exist only because of connectors between roles of the structured classifier are destroyed, including between roles that are non-composite properties.. Actions taken: December 30, 2004: received issue Reply-To: From: "Conrad Bock" To: "Thomas Weigert" , "'Branislav Selic'" , Subject: RE: Ballot 11 resolutions? Date: Fri, 21 Oct 2005 11:00:13 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, Bran, Comments on the Composite WG proposals. Conrad - Issue 8031: Destruction semantics in StructuredClassifier It says: Marking this issue as closed, as the proposed text is already essentially contained in the specification, in the section on connectors, please see p.171 of the current spec, Semantics of connector: "All links are destroyed when the containing classifier instance is destroyed." Note that the all links here refers to links due to connectors. So this is precisely what the proposed revised text is saying, ignoring that this is now proposed as a semantic variation. This would make the text inconsistent, as in the connector section this is not a semantic variation. The sentence "All links are destroyed when the containing classifier instance is destroyed." doesn't say which links. It is exactly the clarification above that the proposal addresses The proposed text was moved to a semantic variation because Bran didn't want it required. Presumably he would disagree with your interpretatioin of the existing text. The proposal is: In Section 9.3.13., subsection "Semantic Variation Point" add new paragraph at the end "When an instance of a structured classifier is destroyed, all links may be destroyed that exist only because of connectors between roles of the structured classifier. This clarifies the existing text and satisfies Bran's request that the semantics be a variation point. - Issue 8026: Contextualized attribute values Figures 121 http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000020 I think waiting a month to respond and delaying on the last ballot isn't good process. I would like this included in ballot 11. Your comments on the web were: > I don't think this is ready for prime time for two reasons: > There are discussions in other groups for a different use of this > graphical construct, e.g., in Sys ML? to show nested parts. I think > that this is a sensible idea, however. The SST proposal already has this presentation option. It is useful generally. The lines in the diagram are still unclear. Maybe you could show the Buy Sell Dialog Class? definition, so that it would be more obvious what you are talking about with those lines. You say they are connectors, but (i) what do the role names mean (I know they are legal, but really have no meaning at all in UML, but you seem to attach semantics to them); (ii) they really appear to be more like associations in your example. The lines are connectors, as in an any composite structure diagram. As the text explains, this just modifies it to support shoing To: Cc: "Thomas Weigert" , uml2-rtf@omg.org Subject: RE: Ballot 11 resolutions? X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 24 Oct 2005 18:10:30 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 10/24/2005 18:10:40, Serialize complete at 10/24/2005 18:10:40 I agree with Conrad's ammendment on issue 8031. As for issue 8026, since there seems to be no consensus after a lot of discussion, I suggest that Thomas propose a resolution on which the RTF can vote. Conrad and others who have the same objections as he should freely lobby the other RTF members stating their objections and urging a "no" vote on that resolution proposal. The latter is to ensure that voters are fully informed of the contention about the proposed resolution. Cheers, Bran "Conrad Bock" 10/21/2005 11:00 AM Please respond to conrad.bock To "Thomas Weigert" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: Ballot 11 resolutions? Hi Thomas, Bran, Comments on the Composite WG proposals. Conrad - Issue 8031: Destruction semantics in StructuredClassifier It says: Marking this issue as closed, as the proposed text is already essentially contained in the specification, in the section on connectors, please see p.171 of the current spec, Semantics of connector: "All links are destroyed when the containing classifier instance is destroyed." Note that the all links here refers to links due to connectors. So this is precisely what the proposed revised text is saying, ignoring that this is now proposed as a semantic variation. This would make the text inconsistent, as in the connector section this is not a semantic variation. The sentence "All links are destroyed when the containing classifier instance is destroyed." doesn't say which links. It is exactly the clarification above that the proposal addresses The proposed text was moved to a semantic variation because Bran didn't want it required. Presumably he would disagree with your interpretatioin of the existing text. The proposal is: In Section 9.3.13., subsection "Semantic Variation Point" add new paragraph at the end "When an instance of a structured classifier is destroyed, all links may be destroyed that exist only because of connectors between roles of the structured classifier. This clarifies the existing text and satisfies Bran's request that the semantics be a variation point. - Issue 8026: Contextualized attribute values Figures 121 http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000020 I think waiting a month to respond and delaying on the last ballot isn't good process. I would like this included in ballot 11. Your comments on the web were: > I don't think this is ready for prime time for two reasons: > There are discussions in other groups for a different use of this > graphical construct, e.g., in Sys ML? to show nested parts. I think > that this is a sensible idea, however. The SST proposal already has this presentation option. It is useful generally. The lines in the diagram are still unclear. Maybe you could show the Buy Sell Dialog Class? definition, so that it would be more obvious what you are talking about with those lines. You say they are connectors, but (i) what do the role names mean (I know they are legal, but really have no meaning at all in UML, but you seem to attach semantics to them); (ii) they really appear to be more like associations in your example. The lines are connectors, as in an any composite structure diagram. As the text explains, this just modifies it to support shoing default property values on the type of a part. Reply-To: From: "Conrad Bock" To: "Thomas Weigert" , "'Branislav Selic'" Cc: Subject: RE: Ballot 11 resolutions? Date: Tue, 25 Oct 2005 18:28:09 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > 1. Regarding 8031: > > It is inappropriate to have different sections of the > specification say inconsistent things. Personally, I think that > the existing text is perfectly clear. However, in the interest > of compromise I suggest to add the additional wording that > Conrad thinks provides additional detail into the existing text. > However, it should be inserted in the connector chapter, as > there is already text discussing the destruction of connectors. > > So, what about resolving 8031 in the following manner: > > In section 9.3.6. "Connector", subsection "Semantics", replace > the last sentence of the 2nd paragraph by: > > "All such links corresponding to connectors are destroyed, when > the containing classifier instance is destroyed." > > This reflects Conrad's phrasing "all links that exist only > because of connectors between roles of the structured > classifier". However, I use "corresponding to connectors" to > match the sentence before, where we talk about the creation of > links corresponding to connectors. The connectors being > destroyed are precisely those connectors that we speak about in > the previous sentence. I think this is clearer. This is fine with me, if it is clear from context that the connectors referred to are the ones owned by the class(es) of the object being destroyed. There could be links due to connectors owned by other classes, and these should not be destroyed. > 2. Regarding 8026: > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000020 > I have been asking for an explanation of the diagram with > Conrad's proposal, but still have not received such. That was on the 20th of this month, after a gap of a month since I posted the last revision. > understand this diagram. Certainly I cannot support a resolution > if I cannot understand what it actually is proposing. Agreed, it's just that there was a month when I didn't know you didn't understand, and it's getting late now. Water under the bridge in any case. > So, please, Conrad, can you give a clear explanation of what the > diagram means that you added to the TWiki. It would be best to > give a repository model, or at least, a clear description of how > this diagram maps onto a meta model. This is a proposal for the Presentation Option section, so the underlying model is no different than usual. The only change is in a optional notation in the structure diagram to show the properties of the classes of the parts (properties). The text is: "Default values for properties of the type of properties in a composite structure can be shown in the property symbol with the same syntax as properties on a class, for example, as shown in Figure ?." It doesn't indicate any other changes to the notation, so everything else is interpreted as normal, eg, lines between part rectangles are connectors, etc. Perhaps the text could be generalized to refer to all aspects of property notation, rather than focus on default values, and use the terminology of the structured classifier, and explain the diagram better. How about: "Properties of the type of properties of roles in a structure diagram can be shown inside the role symbol with the same syntax as properties on a class, for example, as shown in Figure ?. It shows a structured classifier with parts called name, buySellMenu, and okCancel. The properties of the types of these parts are shown in the rectangles for each part." Subject: RE: Ballot 11 resolutions? Date: Thu, 27 Oct 2005 03:15:26 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Ballot 11 resolutions? Thread-Index: AcXZ3AtV4fAUG6LHTmSK9+EqSivaugBAmTVw From: "Mellor, Stephen" To: "Thomas Weigert" , , "Branislav Selic" Cc: X-OriginalArrivalTime: 27 Oct 2005 10:13:55.0941 (UTC) FILETIME=[23944950:01C5DADF] I remained concerned about Issue 8031. The proposed revised text reads: Revised Text In section 9.3.6. "Connector", subsection "Semantics", replace the last sentence of the 2nd paragraph by: "All such links corresponding to connectors are destroyed, when the containing classifier instance is destroyed." Now, I have been assured that this has to do only with connectors (whatever they are), and it does not imply deletion of linked instances. That is, if a Customer is deleted, any unconditionally associated (linked, connected?) accounts are not automatically deleted. What we need for the action model is that deletion of instances of classes and associations are *all* made explicit. There are myriad reasons for this, which I can rehearse at length, but if you can assure me, that "connectors" means something other than instances of classes and associations, then I won't have to, will I? It would help if the phrase "such links corresponding to connectors " were expanded a little. Thanks. -- stephen From: "Thomas Weigert" To: "'Mellor, Stephen'" , , "'Branislav Selic'" Cc: Subject: RE: Ballot 11 resolutions? Date: Thu, 27 Oct 2005 07:03:25 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 Stephen, so sorry, please look at the section on connectors. A connector is not at the instance level, but specifies contextual links. If you read the section 9.3..6, the sentence immediately preceding the changed sentence below speaks about links that are created corresponding to connectors. This sentence then talks about the very same links being deleted when the containing instance is destroyed. As I said earlier, this is already in the text, and only rephrased to make explicit this is only talking about links due to these connectors. This change does not change anything other than wording. Th. Reply-To: From: "Conrad Bock" To: "Thomas Weigert" , "'Branislav Selic'" Cc: Subject: RE: Ballot 11 resolutions? Date: Thu, 27 Oct 2005 14:55:15 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > 1. From your augmented figure on the wiki it is hard to picture > "tabTo" as a connector. Your class definitions show an association > tabTo going from a DialogControl to another DialogControl. Presumably > that is a link from one dialog control to another indicating the > sequence along which you would pass were you to hit the tab key.... tabTo is the name of the association end, the connectors just tell how to instantiate the association in a particular dialog box. > A connector would typically be used to pass information between > instances. For that, the DialogControl should have some behavior > that can respond to the communication or initiate communication. Connectors also create links between instances, and these links can be used in various ways, communication among them. In this example, whatever process takes care of changing focus in the dialog uses the tabTo links to tell where the focus goes to next, ie, the link is used for navigation. > 2. You say this is not related to initialization. But I thought the whole > intention of this notation was to define how property values are > initialized. Otherwise, it should be an instance model. I think what you > meant to say is that showing the initial value in the property is no > different from showing it as part of the definition of the property. The > reason why I had asked to show an initializer was to get clear on how you > meant the instance of BuySellDialogClass to look. The intention is just to show the class information of the part type on the structure diagram. There isn't any change to initialization. I put in default values for completeness (initial values actually, but I couldn't that name changed). > In any case, it appears to me that this is just a poor example to > illustrate your point. But let me see whether I got it right: You are > saying that BuySellDialogClass has three properties, name (a > TextBox), buySellMenu (a DropDownMenu), and okCancel (an > OKCancelButton). These properties are initialized in their attributes > as shown. That's right. > >From this example I conclude that you just mean to allow to show initial > values for attributes. > > Is there a constraint that these values have to be the same as in the > definition of the types of the properties? Or are these defining an > initializer that might be different from the default values as > defined in the class definition? What about properties that are not > just attributes, and internal structure? What makes attributes > privileged that these can be shown but not other properties? The default values shown in the structure diagram are the same as in the class diagram. No additional constraints. Perhaps the example seems little strange because each dialog class will have different default values for the attributes. This is achieved with subclasses of the DropDownMenu, etc, but I didn't show them for space reasons. Things would be easier with an explicit model of contextualized attribute values, but am proposing the presentation option as a compromise.