Issue 14629: UML 2 Events referred to by OccurrenceSpecifications should be optional (uml2-rtf) Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org) Nature: Uncategorized Issue Severity: Summary: In UML 2, every OccurrenceSpecification must be associated with an Event. The Event in turn should have a name and an owning package. But in general, drawing an interaction diagram does not specify a name or owner for the Events associated with the OccurrenceSpecifications. This means that conforming tools have to invent Events including their names and owners for all OccurrenceSpecifications in an Interaction, even though these objects have no relevance to the model. This simply consumes memory footprint without providing any user value. If people want to model Events, that is fine; if they wish to associate OccurrenceSpecifications with them that is fine too; what is not fine is forcing the existence of these spurious objects. Hence the multiplicity of OccurrenceSpecification.event and its redefinitions should be changed to 0..1. Resolution: The Events that are only defined for Interactions are superfluous and is removed. The necessary information is in the Signal or Operation designated by the signature property of Message together with the MessageKind and MessageSort properties. In UML 2.3 the signature attribute is derived, in this revision it is changed to non-derived. Revised Text: (notice that all references are to the section numbering from UML 2.3 superstructure) Model changes and their derived figure changes: Delete the following classes: ExecutionEvent, CreationEvent, SendOperationEvent, SendSignalEvent, ReceiveOperationEvent, ReceiveSignalEvent Delete the association from OccurrenceSpecification to Event. Delete the association from ExecutionOccurrenceSpecification to ExecutionEvent (actually follows by necessity when ExecutionEvent is removed) Modify the association from ExecutionOccurrenceSpecification to ExecutionSpecification such that the multiplicity at the ExecutionOccurrenceSpecification is 0..2 Modify the association from Message to NamedElement with role „signature? such that it is no longer derived and readOnly. The Figures are affected as follows: Figure 14.2 is removed Figure 14.3 should add DestructionOccurrenceSpecification as a specialization of OccurrenceSpecification. Figure 14.5: The class Event and its association should be removed. The association from Message to NamedElement („signature?) should not be derived. Figure 14.6: Change multiplicity on back end of the „execution? association. Remove ExecutionEvent and its association from ExecutionOccurrenceSpecification. (Follows automatically from model changes) Text changes in the 14.3 Class Descriptions: The following sections are removed, and subsequently sections must be renumbered: 14.3.6 CreationEvent, 14.3.8 ExecutionEvent, 14.3.27 ReceiveOperationEvent, 14.3.28 ReceiveSignalEvent, 14.3.29 SendOperationEvent, 14.3.30 SendSignalEvent. Individual changes in the class descriptions: In class 14.3.20 Message: The following text should be replacing the description of the signature association: The signature of the Message is the specification of its content. It refers either an Operation or a Signal. The first constraint should read: [1] If the sendEvent and the receiveEvent of the same Message are on the same Lifeline, the sendEvent must be ordered before the receiveEvent. Add a new constraint (adapted from the deleted CreationEvent) [8] Where messageSort = createMessage, no other OccurrenceSpecification on a given Lifeline in an InteractionOperand may appear above an OccurrenceSpecification that is the receiveEvent of this creation Message. The last three paragraphs of the Semantics section should read (the last paragraph should be eliminated): When a Message represents an Operation, the arguments of the Message are the arguments of the Operation. When a Message represents a Signal, the arguments of the Message are the attributes of the Signal. Under Notation, under the line of “Object creation Message” another line should be included: Object deletion Message should end in a DestructionOccurrenceSpecification. For class 14.3.7 DestructionEvent: Rename the class DestructionEvent to DestructionOccurrenceSpecification and replace the name everywhere in the description of 14.3.7. Replace “DestructionEvent” with “DestructionOccurrenceSpecification” also in Table 14.1 and Table 14.6 (3 mentions in total). In section on Generalizations ? “OccurrenceSpecification (from BasicInteractions)” on page TBD with the appropriate reference to page. The Section Constraints should read: [1] No other OccurrenceSpecifications on a given Lifeline in a given InteractionOperand may appear below a DestructionOccurrenceSpecification. In class 14.3.9 ExecutionOccurrenceSpecification In section Associations, Remove the event association. In class 14.3.23 MessageOccurrenceSpecification: In section Associations Remove the event association. Therefore the section should read: No additional associations. In class 14.3.25 OccurrenceSpecification In section Associations Remove the event association. Replace twice in 14.3.25 “EventOcurrences” by “OccurrenceSpecifications”. (This is an old spelling mistake.) Actions taken: November 6, 2009: received issue April 25, 2011: closed issue Discussion: End of Annotations:===== m: Steve Cook To: "issues@omg.org" Subject: UML 2 Events referred to by OccurrenceSpecifications should be optional Thread-Topic: UML 2 Events referred to by OccurrenceSpecifications should be optional Thread-Index: Acpe11MDEqbzd+GkTsutgtTnBqu1Hw== Date: Fri, 6 Nov 2009 11:50:23 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: In UML 2, every OccurrenceSpecification must be associated with an Event. The Event in turn should have a name and an owning package. But in general, drawing an interaction diagram does not specify a name or owner for the Events associated with the OccurrenceSpecifications. This means that conforming tools have to invent Events including their names and owners for all OccurrenceSpecifications in an Interaction, even though these objects have no relevance to the model. This simply consumes memory footprint without providing any user value. If people want to model Events, that is fine; if they wish to associate OccurrenceSpecifications with them that is fine too; what is not fine is forcing the existence of these spurious objects. Hence the multiplicity of OccurrenceSpecification.event and its redefinitions should be changed to 0..1. -- Steve Date: Wed, 05 May 2010 13:25:57 -0400 From: "Chonoles, Michael J" Subject: Ballot 8 issues on 14629 To: Steve Cook , "uml2-rtf@omg.org" Thread-Topic: Ballot 8 issues on 14629 Thread-Index: AcrrrFsVF2Kv82qtRkm71PLsEjyo7AAyiCUQ Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Some questions on ballot 8 Issue 14629 The Resolution paragraph ends with the sentence. .In UML 2.3 the signature attribute is derived, and is therefore changed to significant. . What does that mean? Also in the same issue Message constraint [8] new [8] Where messageSort = createMessage, no other OccurrenceSpecification on a given Lifeline in an InteractionOperand may appear above an OccurrenceSpecification that is the receiveEvent of this creation Message. _ a) Aren.t lifelines allowed to be horizontal. The word .above. is refers to a physical ordering It should probably be something like .before. or somehow better clarified. b) I can imagine Alt fragments where 1) more than one createMessage could appear on the same lifeline (though I.m not sure the notation for this is currently possible), and 2) OccurenceSpecifications can appear .above. some of the create messages. Similiarly for the destructionoccurencespecificaiton [1] No other OccurrenceSpecifications on a given Lifeline in an InteractionOperand may appear below a DestructionOccurrenceSpecification. _ a) Figure out a replacement for .below. b) Allow for alt fragments that destroy in different locations. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, May 04, 2010 1:13 PM To: uml2-rtf@omg.org Subject: IMPORTANT: Ballot 8 final review and vote starts today! I have created ballot 8 final today. Please find it in the usual folder in SVN in MS doc and PDF (also attached) formats. Deadline for voting is : May 17th. Please vote using the spreadsheet or by email. I have created a folder for one more ballot. This will close for submissions on May 31st and voting will be completed on it by June 18th. I have moved incomplete resolutions from Ballot 8 draft into Ballot 9 draft. There will be no ballots after Ballot 9. Thanks -- Steve From: Steve Cook To: "Chonoles, Michael J" , Østein Haugen (Oystein.Haugen@sintef.no) CC: "uml2-rtf@omg.org" Subject: RE: Ballot 8 issues on 14629 Thread-Topic: Ballot 8 issues on 14629 Thread-Index: AQHK7HgS6bnpF3fSOUG4BcEGAxSPfZJEFmPw Date: Thu, 6 May 2010 08:47:16 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Michael With regard to .is therefore changed to significant. I take it to mean .is therefore changed to non-derived.. With regard to .above., the spec says in 14.3.19 A Lifeline is shown using a symbol that consists of a rectangle forming its .head. followed by a vertical line (which may be dashed) that represents the lifetime of the participant.. As far as I understand it, your other questions below constitute a new issue: the ability to create and destroy within Alt fragments. I don.t believe there is anything in this resolution that changes the capabilities that exist now. Oystein may wish to comment further. Regards -- Steve From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 05 May 2010 18:26 To: Steve Cook; uml2-rtf@omg.org Subject: Ballot 8 issues on 14629 Some questions on ballot 8 Issue 14629 The Resolution paragraph ends with the sentence. .In UML 2.3 the signature attribute is derived, and is therefore changed to significant. . What does that mean? Also in the same issue Message constraint [8] new [8] Where messageSort = createMessage, no other OccurrenceSpecification on a given Lifeline in an InteractionOperand may appear above an OccurrenceSpecification that is the receiveEvent of this creation Message. _ a) Aren.t lifelines allowed to be horizontal. The word .above. is refers to a physical ordering It should probably be something like .before. or somehow better clarified. b) I can imagine Alt fragments where 1) more than one createMessage could appear on the same lifeline (though I.m not sure the notation for this is currently possible), and 2) OccurenceSpecifications can appear .above. some of the create messages. Similiarly for the destructionoccurencespecificaiton [1] No other OccurrenceSpecifications on a given Lifeline in an InteractionOperand may appear below a DestructionOccurrenceSpecification. _ a) Figure out a replacement for .below. b) Allow for alt fragments that destroy in different locations. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, May 04, 2010 1:13 PM To: uml2-rtf@omg.org Subject: IMPORTANT: Ballot 8 final review and vote starts today! I have created ballot 8 final today. Please find it in the usual folder in SVN in MS doc and PDF (also attached) formats. Deadline for voting is : May 17th. Please vote using the spreadsheet or by email. I have created a folder for one more ballot. This will close for submissions on May 31st and voting will be completed on it by June 18th. I have moved incomplete resolutions from Ballot 8 draft into Ballot 9 draft. There will be no ballots after Ballot 9. Thanks -- Steve Date: Thu, 06 May 2010 05:26:44 -0400 From: "Chonoles, Michael J" Subject: RE: Ballot 8 issues on 14629 To: Steve Cook , Østein Haugen (Oystein.Haugen@sintef.no) Cc: "uml2-rtf@omg.org" Thread-Topic: Ballot 8 issues on 14629 Thread-Index: AQHK7HgS6bnpF3fSOUG4BcEGAxSPfZJEFmPwgAAMkGA= Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Steve Ok, please change the fix to indicate significant àn-derived to match common terminology I can.t find any mention of horizontal SDs, so I assume I must have imagined this. However, it is possible to create and destroy in alt fragments. See Figure 14.11 where both are done. Michael From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, May 06, 2010 4:47 AM To: Chonoles, Michael J; Østein Haugen (Oystein.Haugen@sintef.no) Cc: uml2-rtf@omg.org Subject: RE: Ballot 8 issues on 14629 Michael With regard to .is therefore changed to significant. I take it to mean .is therefore changed to non-derived.. With regard to .above., the spec says in 14.3.19 A Lifeline is shown using a symbol that consists of a rectangle forming its .head. followed by a vertical line (which may be dashed) that represents the lifetime of the participant.. As far as I understand it, your other questions below constitute a new issue: the ability to create and destroy within Alt fragments. I don.t believe there is anything in this resolution that changes the capabilities that exist now. Oystein may wish to comment further. Regards -- Steve From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 05 May 2010 18:26 To: Steve Cook; uml2-rtf@omg.org Subject: Ballot 8 issues on 14629 Some questions on ballot 8 Issue 14629 The Resolution paragraph ends with the sentence. .In UML 2.3 the signature attribute is derived, and is therefore changed to significant. . What does that mean? Also in the same issue Message constraint [8] new [8] Where messageSort = createMessage, no other OccurrenceSpecification on a given Lifeline in an InteractionOperand may appear above an OccurrenceSpecification that is the receiveEvent of this creation Message. _ a) Aren.t lifelines allowed to be horizontal. The word .above. is refers to a physical ordering It should probably be something like .before. or somehow better clarified. b) I can imagine Alt fragments where 1) more than one createMessage could appear on the same lifeline (though I.m not sure the notation for this is currently possible), and 2) OccurenceSpecifications can appear .above. some of the create messages. Similiarly for the destructionoccurencespecificaiton [1] No other OccurrenceSpecifications on a given Lifeline in an InteractionOperand may appear below a DestructionOccurrenceSpecification. _ a) Figure out a replacement for .below. b) Allow for alt fragments that destroy in different locations. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, May 04, 2010 1:13 PM To: uml2-rtf@omg.org Subject: IMPORTANT: Ballot 8 final review and vote starts today! I have created ballot 8 final today. Please find it in the usual folder in SVN in MS doc and PDF (also attached) formats. Deadline for voting is : May 17th. Please vote using the spreadsheet or by email. I have created a folder for one more ballot. This will close for submissions on May 31st and voting will be completed on it by June 18th. I have moved incomplete resolutions from Ballot 8 draft into Ballot 9 draft. There will be no ballots after Ballot 9. Thanks -- Steve From: Østein Haugen To: Steve Cook , "Chonoles, Michael J" CC: "uml2-rtf@omg.org" , Østein Haugen Date: Thu, 6 May 2010 11:27:49 +0200 Subject: RE: Ballot 8 issues on 14629 Thread-Topic: Ballot 8 issues on 14629 Thread-Index: AQHK7HgS6bnpF3fSOUG4BcEGAxSPfZJEFmPwgAAJ8yA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Michael I support Steve's interpretation and I have a few supplementary comments below. There are Interaction diagrams where the lifelines are represented horizontally, but much of the text relates to sequence diagrams as the graphical form. The use of "above" and "below" is not something that was invented in this resolution. This resolution merely rewords and moves these statements. There are a few other uses of "above" and I would not be against finding a better word for what it means, but this is a crosscutting issue which should not affect the metamodel as such. As for two create (or destruct) occurrences on the same Lifeline, this is definitely possible within e.g. an alt-fragment. However, the constraint(s) talk about within every InteractionOperand and then there cannot be such double occurrences of create/destruct and that will be caught by the constraint(s). You are right that there are some trivial notational problems here for create but there should be no metamodel problem (or constraint problem). Steve is right that this question is not affected by this new resolution. Regards, Oystein ---- Dr. Oystein Haugen Senior Researcher SINTEF -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 6. mai 2010 10:47 To: Chonoles, Michael J; Østein Haugen Cc: uml2-rtf@omg.org Subject: RE: Ballot 8 issues on 14629 Michael With regard to .is therefore changed to significant. I take it to mean .is therefore changed to non-derived.. With regard to .above., the spec says in 14.3.19 A Lifeline is shown using a symbol that consists of a rectangle forming its .head. followed by a vertical line (which may be dashed) that represents the lifetime of the participant.. As far as I understand it, your other questions below constitute a new issue: the ability to create and destroy within Alt fragments. I don.t believe there is anything in this resolution that changes the capabilities that exist now. Oystein may wish to comment further. Regards -- Steve From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 05 May 2010 18:26 To: Steve Cook; uml2-rtf@omg.org Subject: Ballot 8 issues on 14629 Some questions on ballot 8 Issue 14629 The Resolution paragraph ends with the sentence. .In UML 2.3 the signature attribute is derived, and is therefore changed to significant. . What does that mean? Also in the same issue Message constraint [8] new [8] Where messageSort = createMessage, no other OccurrenceSpecification on a given Lifeline in an InteractionOperand may appear above an OccurrenceSpecification that is the receiveEvent of this creation Message. _ a) Aren.t lifelines allowed to be horizontal. The word .above. is refers to a physical ordering It should probably be something like .before. or somehow better clarified. b) I can imagine Alt fragments where 1) more than one createMessage could appear on the same lifeline (though I.m not sure the notation for this is currently possible), and 2) OccurenceSpecifications can appear .above. some of the create messages. Similiarly for the destructionoccurencespecificaiton [1] No other OccurrenceSpecifications on a given Lifeline in an InteractionOperand may appear below a DestructionOccurrenceSpecification. _ a) Figure out a replacement for .below. b) Allow for alt fragments that destroy in different locations. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, May 04, 2010 1:13 PM To: uml2-rtf@omg.org Subject: IMPORTANT: Ballot 8 final review and vote starts today! I have created ballot 8 final today. Please find it in the usual folder in SVN in MS doc and PDF (also attached) formats. Deadline for voting is : May 17th. Please vote using the spreadsheet or by email. I have created a folder for one more ballot. This will close for submissions on May 31st and voting will be completed on it by June 18th. I have moved incomplete resolutions from Ballot 8 draft into Ballot 9 draft. There will be no ballots after Ballot 9. Thanks -- Steve Date: Thu, 06 May 2010 05:29:56 -0400 From: "Chonoles, Michael J" Subject: RE: Ballot 8 issues on 14629 To: Østein Haugen , Steve Cook Cc: "uml2-rtf@omg.org" Thread-Topic: Ballot 8 issues on 14629 Thread-Index: AQHK7HgS6bnpF3fSOUG4BcEGAxSPfZJEFmPwgAAJ8yCAAAQHEA== Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Seems fair enough. I withdraw any directions. Michael From: Østein Haugen [mailto:Oystein.Haugen@sintef.no] Sent: Thursday, May 06, 2010 5:28 AM To: Steve Cook; Chonoles, Michael J Cc: uml2-rtf@omg.org; Østein Haugen Subject: RE: Ballot 8 issues on 14629 Michael I support Steve's interpretation and I have a few supplementary comments below. There are Interaction diagrams where the lifelines are represented horizontally, but much of the text relates to sequence diagrams as the graphical form. The use of "above" and "below" is not something that was invented in this resolution. This resolution merely rewords and moves these statements. There are a few other uses of "above" and I would not be against finding a better word for what it means, but this is a crosscutting issue which should not affect the metamodel as such. As for two create (or destruct) occurrences on the same Lifeline, this is definitely possible within e.g. an alt-fragment. However, the constraint(s) talk about within every InteractionOperand and then there cannot be such double occurrences of create/destruct and that will be caught by the constraint(s). You are right that there are some trivial notational problems here for create but there should be no metamodel problem (or constraint problem). Steve is right that this question is not affected by this new resolution. Regards, Oystein ---- Dr. Oystein Haugen Senior Researcher SINTEF -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 6. mai 2010 10:47 To: Chonoles, Michael J; Østein Haugen Cc: uml2-rtf@omg.org Subject: RE: Ballot 8 issues on 14629 Michael With regard to .is therefore changed to significant. I take it to mean .is therefore changed to non-derived.. With regard to .above., the spec says in 14.3.19 A Lifeline is shown using a symbol that consists of a rectangle forming its .head. followed by a vertical line (which may be dashed) that represents the lifetime of the participant.. As far as I understand it, your other questions below constitute a new issue: the ability to create and destroy within Alt fragments. I don.t believe there is anything in this resolution that changes the capabilities that exist now. Oystein may wish to comment further. Regards -- Steve From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 05 May 2010 18:26 To: Steve Cook; uml2-rtf@omg.org Subject: Ballot 8 issues on 14629 Some questions on ballot 8 Issue 14629 The Resolution paragraph ends with the sentence. .In UML 2.3 the signature attribute is derived, and is therefore changed to significant. . What does that mean? Also in the same issue Message constraint [8] new [8] Where messageSort = createMessage, no other OccurrenceSpecification on a given Lifeline in an InteractionOperand may appear above an OccurrenceSpecification that is the receiveEvent of this creation Message. _ a) Aren.t lifelines allowed to be horizontal. The word .above. is refers to a physical ordering It should probably be something like .before. or somehow better clarified. b) I can imagine Alt fragments where 1) more than one createMessage could appear on the same lifeline (though I.m not sure the notation for this is currently possible), and 2) OccurenceSpecifications can appear .above. some of the create messages. Similiarly for the destructionoccurencespecificaiton [1] No other OccurrenceSpecifications on a given Lifeline in an InteractionOperand may appear below a DestructionOccurrenceSpecification. _ a) Figure out a replacement for .below. b) Allow for alt fragments that destroy in different locations. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, May 04, 2010 1:13 PM To: uml2-rtf@omg.org Subject: IMPORTANT: Ballot 8 final review and vote starts today! I have created ballot 8 final today. Please find it in the usual folder in SVN in MS doc and PDF (also attached) formats. Deadline for voting is : May 17th. Please vote using the spreadsheet or by email. I have created a folder for one more ballot. This will close for submissions on May 31st and voting will be completed on it by June 18th. I have moved incomplete resolutions from Ballot 8 draft into Ballot 9 draft. There will be no ballots after Ballot 9. Thanks -- Steve From: Østein Haugen To: Darren Kumasawa , "uml2-rtf@omg.org" CC: Steve Cook , Bran Selic , "Ed Seidewitz" , Maged Elaasar , "Dave Hawkins" , Østein Haugen Date: Fri, 7 May 2010 10:32:48 +0200 Subject: RE: Ballot 8 Draft: A draft resolution on Events in Interactions Thread-Topic: Ballot 8 Draft: A draft resolution on Events in Interactions Thread-Index: AcrtiRNj+xZlSRK2QGyMB2VJF7QR7QANjIEg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Darren You have a good point. My thinking was the following: 1) Destructions are not always the result of a destruction message. (Suicide used to be the only way to destruct). Therefore the DestructionOccurrenceSpecification should not be a MessageEnd. 2) A delete message will thus have a MessageOccurrenceSpecification that overlaps with the DestructionOccurrenceSpecification. 3) The order of such overlapping occurrences will be solved in the next RTF as this has come up as a separate issue, but in this case it is obvious that the MessageOccurrenceSpecification will be ordered before the DestructionOccurrenceSpecification because it needs to be the last thing that happens. Do you find this reasonable? /Oystein ---- Dr. Oystein Haugen Senior Researcher SINTEF -------------------------------------------------------------------------------- From: Darren Kumasawa [mailto:darren.kumasawa@oracle.com] Sent: 7. mai 2010 04:00 To: Østein Haugen; uml2-rtf@omg.org Cc: Steve Cook; Bran Selic; Ed Seidewitz; Maged Elaasar; Dave Hawkins; Østein Haugen Subject: Re: Ballot 8 Draft: A draft resolution on Events in Interactions Hi Oystein, The revised draft says "Rename class DestructionEvent to DestructionOccurrenceSpecification and let it be a specialization of OccurrenceSpecification" and "Object deletion Message should end in a DestructionOccurrenceSpecification" If an object deletion Message should end in a DestructionOccurrenceSpecification, then shouldn't DestructionOccurrenceSpecification inherit from MessageEnd as well as OccurrenceSpecification, or DestructionOccurrenceSpecification should be a specialization of MessageOccurrenceSpecification? Thanks, Darren Kumasawa Oracle Corporation ----- Original Message ----- From: "Østein Haugen" To: Cc: "Steve Cook" ; "Bran Selic" ; "Ed Seidewitz" ; "Maged Elaasar" ; "Dave Hawkins" ; "Østein Haugen" Sent: Thursday, April 29, 2010 10:41 AM Subject: RE: Ballot 8 Draft: A draft resolution on Events in Interactions I have made an update to the Draft Resolution of Issue 14629. I have tried to take the comments into account and I have walked through in greater detail the classes that I suggest to delete. The main statement still remains true, namely that the Events that were produced in the repository for Interactions are never used anywhere else and they contain close to no useful information. Everybody seems to agree to that. I have according to Steve's findings removed the desire to remove also "MessageEvent" since it is used in StateMachines, but none of its concrete subclasses there overlap with those originally in Interactions. As Steve points out, the name MessageEvent is meaningless in State Machines, and the class contains no information, so it could in fact be removed there, too (and its subclasses inheriting directly from Event), but that is not my concern. It is true that I have changed a multiplicity that strictly speaking did not fall under the issue, but it did fall into the scope of my other changes, so I chose to include it. I changed it now to the more restricted 0..2 (rather than * in my first version) because there can never be more than 2 ExecutionOccurrenceSpecifications referring to the same ExecutionSpecification. (Please note that ExecutionSpecifications need not be bounded only by ExecutionOccurrenceSpecifications. The tools are free to apply only one OccurrenceSpecification representing the start of an ExecutionSpecification and the end of a synchronous message (i.e. an Operation call). In principle also other OccurrenceSpecifications can be "reused". Typically a finish of an ExecutionSpecification can coincide with the sending of a reply message. This is not affected by my resolution proposal, but has been this way always in UML2.) Dave asked for instance diagrams. If you mean illustrations of how the repository should be for some examples, that may certainly be useful, but you do not find those anywhere else in the standard? If you mean figures and examples, there are not that few examples in Interaction chapter, but I do agree that there could be even more. Regards, Oystein ---- Dr. Oystein Haugen Senior Researcher SINTEF -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 28. april 2010 16:59 To: Østein Haugen Cc: Steve Cook; Bran Selic; Ed Seidewitz; Maged Elaasar; uml2-rtf@omg.org Subject: Re: Ballot 8 Draft: A draft resolution on Events in Interactions Oystein, This resolution seems to be including fixes for a number of things that aren't related to the issue Steve logged. Specifically, changing the multiplicty of the ExecutionSpecification-ExecutionOccurrenceSpecification association and updating some typos. The first of those is actually a serious issue in its own right and I'm a little uncomfortable that it's being tacked onto this resolution as OMG members might not vote in favour of the full resolution. Interaction events have caused us a bit of a headache in our implementation, although that is primarily because they can only be owned by packages. (As Maged and I'm fairly certain Nerijus previously have suggested, events owned by BehaviouredClassifiers would make managing them much easier.) Eliminating events from interactions would certainly resolve that, however I remain concerned about those areas of the specification that use events in general. For example, a trigger can reference an event. There's nothing to say that it couldn't be referencing one of the events proposed for removal and this is a mandatory property. The resolution isn't clear how a DestructionSpecification would actually be used. (This is a general problem with the Interactions specification, it lacks instance diagrams and is overly open to vendor interpretation.) Does it replace the MessageOccurrenceSpecification at the end of a deleteMessage? Does it follow it? And why isn't it called DestructionOcurrenceSpecification? Cheers, Dave Steve Cook wrote: > Oystein > > > > In general, your resolution talks about deleting and modifying > associations, but does not identify the consequential specific textual > changes - the one Bran identified was one case of this. We're very > pushed in this RTF, so getting the textual changes complete is a > pre-requisite for making the resolution acceptable. > > > > Deleting CreationEvent takes along with it the following constraint: [1] > No other OccurrenceSpecification may appear above an > OccurrenceSpecification which references a CreationEvent on a given > Lifeline in an InteractionOperand. > > Should there not be a semantically equivalent constraint re-introduced > elsewhere, e.g. on Message or on OccurrenceSpecification? > > > > The following are subtypes of MessageEvent: AnyReceiveEvent, > SignalEvent, CallEvent (fig 13.12). Your resolution doesn't mention > them. They are used in Actions, State Machines, etc. So I don't believe > you can delete MessageEvent. If you don't delete MessageEvent, since it > will now not be used in interactions, what is the significance of > "Message" in its name? > > > > You say 'Replace "EventOccurrences" by "OccurrenceSpecification"'. This > should read 'Replace "EventOccurrences" by "OccurrenceSpecification*s*"' > > > > I am not wholly opposed to trying to shoehorn this in, but it needs to > be significantly improved. > > -- Steve > > > > > > *From:* Østein Haugen [mailto:Oystein.Haugen@sintef.no] > *Sent:* 27 April 2010 12:41 > *To:* Bran Selic > *Cc:* Ed Seidewitz; Maged Elaasar; uml2-rtf@omg.org; Østein Haugen > *Subject:* RE: Ballot 8 Draft: A draft resolution on Events in Interactions > > > > Bran > > You are right about the mentioned association. In the model itself it > would follow from the elimination of ExecutionEvent, but in the text it > would not follow automatically (unfortunately). I had it in my > handwritten notes, but failed to transfer it to the incremental > resolution. I consider this a normal effect of the fact that this is a > draft and it is reasonable that such minor mistakes are discovered. I > had intended to show the final metamodel diagrams, but the RSM models do > not have all the diagrams available. > > > > I agree that I should have done this long time ago and not in the last > ballot. I apologize. However, I found that it has gradually become more > broken than I had thought and found that the model actually does not at > all reflect what the user defines in an Interaction. This really needs > simplification again. As far as I can see you do not have a real > technical argument against the change, but you fear that there may be > something hidden down there some place? Continuing to make the current > approach more elaborate, is going the wrong direction. I wanted to point > that out, for now or later. > > > > What to do with the existing models? I have understood that the models > of Interaction are not all that interoperable and I have also indirectly > understood that different vendors jump to the wrong conclusions about > the layout of the Interaction models. Therefore it is hard to say what > should be done with the old models. If the models keep explicitly > the "signature" association, however, there should be only removing the > Event objects, plus redefining the DestructionEvent to > DestructionOccurrence when applicable. If the 'signature' association is > not expicit in the model, then that association must be derived from the > old model. > > > > The UML users will not experience this change at all. They have never > known anything about Events. Events represent a lot of unnecessary > plumbing in my opinion. The Message (and thereby its signature) is what > the user sees and manipulates, but in the current version this is > "derived" in a rather cryptic way. This is in my opinion the problem. > > > > /Oystein > > > > ---- > > Dr. Oystein Haugen > > Senior Researcher > > SINTEF > > > > > > ------------------------------------------------------------------------ > > *From:* bran.selic@gmail.com [mailto:bran.selic@gmail.com] *On Behalf Of > *Bran Selic > *Sent:* 27. april 2010 13:05 > *To:* Østein Haugen > *Cc:* Ed Seidewitz; Maged Elaasar; uml2-rtf@omg.org > *Subject:* Re: Ballot 8 Draft: A draft resolution on Events in Interactions > > Oystein, > > I notice that your resolution is incomplete, since it does not remove > the appropriate text in the metaclass > *ExecutionOccurrenceSpecification*; i.e.,: > > *Associations* > * event : ExecutionEvent [1] Redefines the event referenced to be > restricted to an execution event. > > > I did not check in other places, but it is a sign that this kind of > change can be tricky and may even have repercussions. Based on that, I > tend to agree with folks who are nervous about this type of change at > this stage (last ballot). My experience in the past is that the last > ballot should be reserved for less extensive fixes. > > Furthermore, I do think that /any fix that modifies the metamodel should > include a recommendation on how existing models should deal with the > change /(e.g., do they simply delete things in the models or do they do > some kind of transformation to conform the new metamodel? etc.). Since > Interactions is one of the most widely used features of UML, the impact > of this change on existing metamodels and, hence, UML users, could be > quite significant. > > Cheers...Bran > > 2010/4/27 Østein Haugen > > > Dear Ed and Maged > > You have both expressed concern about my resolution to 14629. Your > concern is that this is such a big change. I am not so sure it is. > > > > I put time into this and suggested the resolution because I was under > the impression that this was the time for changing the metamodel. In 2.5 > that cannot be done. Therefore it is necessary to do it now. Since the > metamodel is changed, all tools must change accordingly and > interoperability must be tried again. > > > > Is the change drastic? In a way it is since it eliminates the use of > Events and its subclasses in Interactions. In another way it is not. The > Interaction users never sees Events and they never explicitly model > them. In fact I am quite sure that no Event objects created implicitly > by the tool in an Interaction diagram are used anywhere else. This > latter statement is the heart of the issue. Events were originally > invented during UML 2.0 very late and it was intended to form a bridge > between different kinds of behavioral descriptions. But it does not > function that way - at least not for Interactions. Therefore the Event > objects are merely there to describe something which is easier done > directly and the way it was originally designed (by me in early UML 2.0). > > > > The user defines the kind, sort and name of the Message. There is > concrete syntax for that. The name of the Message (and its arguments) > correspond to a 'signature' which is either an Operation (if it is > synchronous) or a Signal (if it is asynchronous). This is the > significant information and the information any analysis tool will use > when comparing (say) state machines and Interactions. The signature > objects _are shared_ between different behavioral and structural > descriptions in the same UML model. In the 2.3 version the signature is > derived and this is very backward since the signature is exactly what > the interaction modeler defines directly. > > > > Two points that also may be relevant: > > 1) Interactions do not define any implicit Actions on the Message ends. > This misunderstanding has come from somewhere, probably from the fact > that at runtime there must exist some action execution for a message to > be sent and received, but this is not something that the Interactions > define in detail. The metamodel should only represent the information > that the modeler actually conveys. Actions may explicitly be defined > through ExecutionSpecifications. > > 2) The term "event" is used also in connection with the semantics of > Interactions (as pointed out by Maged), but this is because the term > "event" was earlier used for what is now termed > "occurrencespecification". This term changed when Event was introduced. > Thus there is still some term confusion, but we can live with that. The > Event concept is not at all used for the tracebased semantics of > Interactions. The information of the "event" in the traces come from the > occurrence specification and its associated message signature. > > > > It is still my opinion that eliminating the Events will simplify the > Interactions metamodel. It will of course have effect on the tools, but > all metamodel changes do. > > > > Regards, > > Oystein > > > > ---- > > Dr. Oystein Haugen > > Senior Researcher > > SINTEF > > > > > > ------------------------------------------------------------------------ > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com > ] > *Sent:* 26. april 2010 23:18 > *To:* Østein Haugen > *Cc:* uml2-rtf@omg.org > *Subject:* RE: Ballot 8 Draft: A draft resolution on Events in Interactions > > Oystein - > > > > Sorry I have not had time to engage in the discussion of this issue. > However, regardless of the technical merits of your resolution, this > seems to be a very large and significant change to be introducing in UML > 2.4 at all, let alone at the last minute before the last ballot. While I > was never a fan of the special set of events defined in the Interactions > clause, it always worries me change like this one, which seems to hit at > a fundamental way in which interactions were previously structured, can > end up introducing more unexpected issues than the issue they resolve. > > > > You also state this resolution will have "cascading effects" on the > resolution of other issues. But, if this is so, it again seems like > there was a fundamental problem in the way that interactions were > constructed before, and I wonder if we are missing something in simply > ripping out a part of the metamodel in seeking resolution to these problems. > > > > Finally, before we do something this drastic, I would like to make sure > that we are really resolving the problems that Nerijus and others > brought up in the MIWG. To my mind, Issue 14629 may identify an > annoyance but it is not a "showstopper". However, the issues that > Nerijus brought up, if valid, would, indeed, be showstoppers for which > drastic measures could be considered in this RTF. > > > > -- Ed > > > > ------------------------------------------------------------------------ > > *From:* Østein Haugen [mailto:Oystein.Haugen@sintef.no > ] > *Sent:* Monday, April 26, 2010 1:11 PM > *To:* uml2-rtf@omg.org > *Cc:* Østein Haugen > *Subject:* Ballot 8 Draft: A draft resolution on Events in Interactions > > > > UML 2.4 RTF > > I have put in a resolution to fixing Events in Interactions which in > practice means eliminating them from Interactions (but not from anywhere > else). This will change and simplify the metamodel. > > > > Please review. I am sure there might be reactions. > > > > Even though this is a resolution to only one Issue, there will be > cascading effects to solving a number of the other outstanding > Interaction issues. > > > > Regards, > > Oystein > > > > ---- > > Dr. Oystein Haugen > > Senior Researcher > > SINTEF > > > > > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. Subject: Issue 14629 To: Steve Cook Cc: Steve Cook , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 10 May 2010 10:22:47 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 05/10/2010 10:22:53 IBM votes Yes on all resolutoins in ballot 8, except for resolution 14629 to which it votes "No". This issue is not currently written with enough instructions for the editor to know what to do exactly.to update the specification doc itself, i.e. it does not talk about section numbers, changed figure numbers...etc., This could lead to editor "discovering" these manually, which could be error prone. . I would prefer this issue get pulled from ballot 8 and reassigned to 9, after doing the proper formatting. Maged Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Steve Cook wrote on 05/07/2010 05:41:22 AM: > I have published a slightly revised version of Ballot 8 Final. This > contains fixes to resolution 10591 to correct some problems with the > proposed revised metamodel. > > Those companies that have already voted are encouraged to check that > you are happy with these changes to 10591. > > Thanks > -- Steve > > From: Steve Cook [mailto:Steve.Cook@microsoft.com] > Sent: 04 May 2010 18:13 > To: uml2-rtf@omg.org > Subject: IMPORTANT: Ballot 8 final review and vote starts today! > > I have created ballot 8 final today. Please find it in the usual > folder in SVN in MS doc and PDF (also attached) formats. > > Deadline for voting is : May 17th. Please vote using the > spreadsheet or by email. > > I have created a folder for one more ballot. This will close for > submissions on May 31st and voting will be completed on it by June 18th > . I have moved incomplete resolutions from Ballot 8 draft into > Ballot 9 draft. > > There will be no ballots after Ballot 9. > > Thanks > -- Steve[attachment "UML 2.4 Resolutions Ballot 8 Final.pdf" deleted > by Maged Elaasar/Ottawa/IBM] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=KccNuWLUKMPBk1QoLxW1MAl0uXD3O6sSzyUGiSybmHw=; b=AKx9OwjmGE8SAUE22skWQgoYSiYte3JlKbv996xqTqMcpOVoXnXqmWsuquSQ7tgQeD /Ot50JgNsA4Ot+NNICLjVIVEqT1F58d2A7y0lPTSdCSIagsbpVc712a7NRjbOyZWGDe0 vwVJeMUIoNojXCBUPJDEN5dPB9iNRFv2aMOoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=qUffrs/9KzFosU3XzEGpATr9qaUgrv+B5XQJchTaBqSzncVoYhLOmhH23UizzUg5KP wp01MyH1w02nC4Dq41U9f/OIxUm+Kqz+TyLKmXZnUiSW/kin19cOzIpeziU3vRVwBf2+ 26aRBKta2Y5k0OSg+rT2PbOKpLajZjKyk5UfY= Sender: bran.selic@gmail.com From: Bran Selic Date: Mon, 10 May 2010 16:39:13 +0200 X-Google-Sender-Auth: ZXw9vEjeXot1hbefry_pOuzegf4 Subject: Re: Issue 14629 To: Maged Elaasar Cc: Steve Cook , "uml2-rtf@omg.org" Excellent point, Maged. Even though I do not have a vote, I strongly support your position. In principle, every resolution should be formulated such that someone (including an automaton) without any knowldege of UML or the spec, should be able to make the necessary changes to the text and diagrams. However, many (perhaps even most) RTF members are very cavalier about this and assume that it's the editor's job to figure it out. Unfortunately, based on my experience, there are often cases where it is not fully clear even to a knowledgable editor as to how to properly interpret and implement an adopted resolution -- which, of course, can lead to further issues with the spec (which has happened in the past). Furthermore, this attitude shows disrespect for the spec editor, who has a tedious and thankless task to start with. I have stressed this point many times when I was the editor of the spec, but it has never been taken to heart by many RTF members and, it seems to me that recently things have become even looser in thsi regard. In my opinion the editor should have the right to veto resolutions in the draft ballots based on this criterion. My appeal to the RTF members: Please respect your editor and do your best to make his/her job as straightforward as possible. Cheers...Bran On Mon, May 10, 2010 at 4:22 PM, Maged Elaasar wrote: IBM votes Yes on all resolutoins in ballot 8, except for resolution 14629 to which it votes "No". This issue is not currently written with enough instructions for the editor to know what to do exactly.to update the specification doc itself, i.e. it does not talk about section numbers, changed figure numbers...etc., This could lead to editor "discovering" these manually, which could be error prone. . I would prefer this issue get pulled from ballot 8 and reassigned to 9, after doing the proper formatting. Maged From: Østein Haugen To: Bran Selic , Maged Elaasar CC: Steve Cook , "uml2-rtf@omg.org" , Østein Haugen Date: Mon, 10 May 2010 17:14:47 +0200 Subject: RE: Issue 14629 Thread-Topic: Issue 14629 Thread-Index: AcrwTvd9LdzBfOg9TLqHxqL8UG6ZMQAAb8Hw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Maged, Bran In general it is always good to give unambiguous instructions, but it may not always be so obvious what is unambigous. In Issue 14629 the first part of the resolution refers to the model from which the meta-model figures are taken. I thought it was obvious that every model figure should be regenerated for a new version of the spec. I cannot see that the instructions are ambiguous if interpreted as instructions to how to manipulate the underlying RSM model. Of course it is possible to relate to the individual Figure numbers, but the point is that these are model changes not diagram changes. In fact I would have produced the new diagrams if the old ones were available, but not all of them were available in RSM form. As for the description of the metaclasses (within one chapter), the class names are unambiguous, while the section numbers will in fact be renumbered when some of the classes are deleted. The resolution refers to the metaclass names (also visualized in bold) and the unnumbered sections below the class levels (such as e.g. "Semantics") are referred also by bold face. I am surprised that this is subject to guessing from the editor? The new text is always shown in full sentences or paragraphs. When you say "proper formatting", do you mean annotating the resolution text with figure numbers and section numbers from the original UML 2.3 spec? This is, as explained above, easily done and should be considered an editorial thing. I disagree with the claim that my text is ambigous and would be subject to guessing. Regards, Oystein ---- Dr. Oystein Haugen Senior Researcher SINTEF -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 10. mai 2010 16:39 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: Re: Issue 14629 Excellent point, Maged. Even though I do not have a vote, I strongly support your position. In principle, every resolution should be formulated such that someone (including an automaton) without any knowldege of UML or the spec, should be able to make the necessary changes to the text and diagrams. However, many (perhaps even most) RTF members are very cavalier about this and assume that it's the editor's job to figure it out. Unfortunately, based on my experience, there are often cases where it is not fully clear even to a knowledgable editor as to how to properly interpret and implement an adopted resolution -- which, of course, can lead to further issues with the spec (which has happened in the past). Furthermore, this attitude shows disrespect for the spec editor, who has a tedious and thankless task to start with. I have stressed this point many times when I was the editor of the spec, but it has never been taken to heart by many RTF members and, it seems to me that recently things have become even looser in thsi regard. In my opinion the editor should have the right to veto resolutions in the draft ballots based on this criterion. My appeal to the RTF members: Please respect your editor and do your best to make his/her job as straightforward as possible. Cheers...Bran On Mon, May 10, 2010 at 4:22 PM, Maged Elaasar wrote: IBM votes Yes on all resolutoins in ballot 8, except for resolution 14629 to which it votes "No". This issue is not currently written with enough instructions for the editor to know what to do exactly.to update the specification doc itself, i.e. it does not talk about section numbers, changed figure numbers...etc., This could lead to editor "discovering" these manually, which could be error prone. . I would prefer this issue get pulled from ballot 8 and reassigned to 9, after doing the proper formatting. Maged Subject: RE: Issue 14629 To: Østein Haugen Cc: Østein Haugen , Bran Selic , Steve Cook , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 10 May 2010 14:12:56 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 05/10/2010 14:13:03 Oystein, 1- The current editing process for the spec doc does not automatically update the spec document based on model edits. Only the sections and figures that have been pointed out explicitly in resolutions are updated. I did not say it would be impossible for the editor to figure out these changes, I said it is more error-prone than if it was done by the submitter and subjected to the review of the group. In the past, changes at this level were not accepted as "editorial" and had to be ballotted. 2-The current style of the resolution leads to ambiguities as to what exactly was the intent of some changes: For example, the resolution currently says: "Rename class DestructionEvent to DestructionOccurrenceSpecification and let it be a specialization of OccurrenceSpecification." Currently, DestructionEvent specializes Event (from Communication). Does the change suggest I replace the current specilization? or append to it? Had you specified the new specialization section, it would have eliminated the ambiguity. 3- The resolution has some omissions : - The description of "DestructionEvent" currently says : "A DestructionEvent models the destruction of an object"..., but the resolution did not suggest we change the description, while suggesting changing the constraint. - The same is true about the "semantic" and "notation" sections and the caption of the notation figure of DestructionOccurenenceSpecification, where they need to be updated bec. they reference the old name but not included in the resolution. 4- Also, I find duplicate instructions to remove MessageOccurerenceSpecification::event: In class MessageOccurrenceSpecification: Remove the event association (which is probably a spelling mistake anyway in the document). <== What is exactly the "spelling" mistake here, or did you mean copy/pase mistake? and In class MessageOccurrenceSpecification Remove the event association. 5- Another example, the resolution currently says: "In class OccurrenceSpecification Replace .EventOccurrences. by .OccurrenceSpecifications.. This is an old spelling mistake. " Does that mean I change toBefore and toAfter association description? I think a lot of these issues could have been avoided early on, had the resolution followed a more rigorous style for describing the changes. I still prefer for it to be either updated today or moved to ballot 9. Thanks Østein Haugen Østein Haugen 05/10/2010 11:14 AM To Bran Selic , Maged Elaasar/Ottawa/IBM@IBMCA cc Steve Cook , "uml2-rtf@omg.org" , Østein Haugen Subject RE: Issue 14629 Maged, Bran In general it is always good to give unambiguous instructions, but it may not always be so obvious what is unambigous. In Issue 14629 the first part of the resolution refers to the model from which the meta-model figures are taken. I thought it was obvious that every model figure should be regenerated for a new version of the spec. I cannot see that the instructions are ambiguous if interpreted as instructions to how to manipulate the underlying RSM model. Of course it is possible to relate to the individual Figure numbers, but the point is that these are model changes not diagram changes. In fact I would have produced the new diagrams if the old ones were available, but not all of them were available in RSM form. As for the description of the metaclasses (within one chapter), the class names are unambiguous, while the section numbers will in fact be renumbered when some of the classes are deleted. The resolution refers to the metaclass names (also visualized in bold) and the unnumbered sections below the class levels (such as e.g. "Semantics") are referred also by bold face. I am surprised that this is subject to guessing from the editor? The new text is always shown in full sentences or paragraphs. When you say "proper formatting", do you mean annotating the resolution text with figure numbers and section numbers from the original UML 2.3 spec? This is, as explained above, easily done and should be considered an editorial thing. I disagree with the claim that my text is ambigous and would be subject to guessing. Regards, Oystein ---- Dr. Oystein Haugen Senior Researcher SINTEF -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 10. mai 2010 16:39 To: Maged Elaasar Cc: Steve Cook; uml2-rtf@omg.org Subject: Re: Issue 14629 Excellent point, Maged. Even though I do not have a vote, I strongly support your position. In principle, every resolution should be formulated such that someone (including an automaton) without any knowldege of UML or the spec, should be able to make the necessary changes to the text and diagrams. However, many (perhaps even most) RTF members are very cavalier about this and assume that it's the editor's job to figure it out. Unfortunately, based on my experience, there are often cases where it is not fully clear even to a knowledgable editor as to how to properly interpret and implement an adopted resolution -- which, of course, can lead to further issues with the spec (which has happened in the past). Furthermore, this attitude shows disrespect for the spec editor, who has a tedious and thankless task to start with. I have stressed this point many times when I was the editor of the spec, but it has never been taken to heart by many RTF members and, it seems to me that recently things have become even looser in thsi regard. In my opinion the editor should have the right to veto resolutions in the draft ballots based on this criterion. My appeal to the RTF members: Please respect your editor and do your best to make his/her job as straightforward as possible. Cheers...Bran On Mon, May 10, 2010 at 4:22 PM, Maged Elaasar wrote: IBM votes Yes on all resolutoins in ballot 8, except for resolution 14629 to which it votes "No". This issue is not currently written with enough instructions for the editor to know what to do exactly.to update the specification doc itself, i.e. it does not talk about section numbers, changed figure numbers...etc., This could lead to editor "discovering" these manually, which could be error prone. . I would prefer this issue get pulled from ballot 8 and reassigned to 9, after doing the proper formatting. Maged pic25212.gif