Issue 6126: Target pin notation (uml2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: On CallOperationAction, etc, how do you tell graphically which pin is the target? Resolution: Disposition: Deferred to UML 2.4 RTF Revised Text: Discussion There is no standard way to distinguish the target pin, but this can always be done using the pin name, if the modeler wishes. Disposition: Closed - No Change Actions taken: August 30, 2003: received issue February 20, 2015: closed issue Discussion: This is does not affect usage or implementability enough for the FTF to address. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification. End of Annotations:===== Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Target pin notation On CallOperationAction, etc, how do you tell graphically which pin is the target? ======================================================================== OMG Issue No: 6126 Title: Target pin notation Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: On CallOperationAction, etc, how do you tell graphically which pin is the target? Discussion: This is does not affect usage or implementability enough for the FTF to address. Reply-To: From: "Conrad Bock" To: "'Ed Seidewitz'" , Subject: RE: Proposed issue resolutions, Set 3: Actions -- Low effort changes Date: Fri, 13 Feb 2009 11:50:29 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmIhvkf/NyZSIJHQs6Y59W53bdfOwCiGKUgAABM9XAALUhVIAAETmKwAIjTjpA= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n1DGoTln011881 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1235148629.97776@gwaVw4tKnqPfHt1LCyJP/g X-Spam-Status: No Ed, > Issue 6126 (Target pin notation) > In any case, it is categorized as low priority, so, if it is not an > easy fix requiring little or no discussion, it probably is not going > to get resolved this time around anyway. How about deferring it? > I thought the section in question (12.3.2 Action) _was_ the > specification of the detailed start semantics! No, it's just a sketch, like the semantics of Activity. The details are in Parameter, and a number of other places. > In any case, the text is definitely wrong now, and I think it is > important not to leave it that way. The changes I am suggesting > don't seem particularly more detailed to me than what is there now > -- only more correct. > Do you really object to just the rewrite of the first paragraph, or > do you also object to the changes to the numbered items? If the > former, could you provide revised wording for it that is "more > general but doesn't conflict with the detailed start semantics"? Could we try to agree on what this section is supposed to do before changing it? It would be good to keep it high-level, like a guide, rather than a detailed procedure consolidating the semantics that is already stated in other places (people can go to fUML for that). Subject: RE: Proposed issue resolutions, Set 3: Actions -- Low effort changes Date: Fri, 13 Feb 2009 12:20:57 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed issue resolutions, Set 3: Actions -- Low effort changes thread-index: AcmIhvkf/NyZSIJHQs6Y59W53bdfOwCiGKUgAABM9XAALUhVIAAETmKwAIjTjpAAAQZY8A== From: "Ed Seidewitz" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n1DHKJIv011910 Conrad -- I have removed my proposed resolutions for issues 6126 and 8861 from draft ballot 1. I don't have a problem with deferring 6126 -- that can wait until we have time to reconsider a number of issues on pin notation. However, I do think it is important to resolve 8861 in this RTF. Having the semantics of how an action starts in Parameter is just wrong -- parameters in general have nothing to do with the semantics of an action starting, except perhaps for invocation actions, and even then only indirectly. There is only a merge increment for Parameter in activity to provide a place to add a few additional capabilities (streaming, parameter sets, etc.), and only the semantics for those things is (and should be) covered there. The obvious place for defining the start semantics for actions is, well, in the action section. And this seems to be the section that is usually referred to for this semantics. For example, I believe it is the only place that specifies the "accept offers on all input pins together" semantics. This seems pretty important! In any case, in general, let's please start trying to put the semantics for things in more obvious places! -- Ed > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Friday, February 13, 2009 11:50 AM > To: Ed Seidewitz; uml2-rtf@omg.org > Subject: RE: Proposed issue resolutions, Set 3: Actions -- Low effort > changes > > Ed, > > > Issue 6126 (Target pin notation) > > > In any case, it is categorized as low priority, so, if it is not an > > easy fix requiring little or no discussion, it probably is not going > > to get resolved this time around anyway. > > How about deferring it? > > > I thought the section in question (12.3.2 Action) _was_ the > > specification of the detailed start semantics! > > No, it's just a sketch, like the semantics of Activity. The details are > in Parameter, and a number of other places. > > > In any case, the text is definitely wrong now, and I think it is > > important not to leave it that way. The changes I am suggesting > > don't seem particularly more detailed to me than what is there now > > -- only more correct. > > > Do you really object to just the rewrite of the first paragraph, or > > do you also object to the changes to the numbered items? If the > > former, could you provide revised wording for it that is "more > > general but doesn't conflict with the detailed start semantics"? > > Could we try to agree on what this section is supposed to do before > changing it? It would be good to keep it high-level, like a guide, > rather than a detailed procedure consolidating the semantics that is > already stated in other places (people can go to fUML for that). > Disposition: Defer