Issue 8180: Section: 11.3.35 (uml2-rtf) Source: (, ) Nature: Clarification Severity: Minor Summary: Add the specialized statement needed for the association result"OutputPin[1..1] as shown in fig. 155. Add semantics or delete the header. Delete the Examples header as there are none. Resolution: See issue 8155 for disposition Revised Text: In Actions, ReadLinkObjectEndQualifierAction, Attributes, entry for result, description, at beginning add "(Specialized from Action:output)". Actions taken: January 31, 2005: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 31 Jan 2005 10:24:11 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jane Messenger Company: U. S. Geological Survey mailFrom: jmessenger@usgs.gov Notification: Yes Specification: Superstructure Section: 11.3.35 FormalNumber: ptc/04-10-02 Version: 2.0 Draft Adopted RevisionDate: 10/08/2004 Page: 291 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description Add the specialized statement needed for the association result"OutputPin[1..1] as shown in fig. 155. Add semantics or delete the header. Delete the Examples header as there are none. From: "Ed Seidewitz" To: Subject: RE: Ballot 1 (Official start of poll) Date: Wed, 27 Apr 2005 17:31:35 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-index: AcVBmfEOht/RnPK9The7fvfqJ02wXAE0TvcwAUD9T9A= X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail4.opentransfer.com X-Spam-Status: No, hits=1.2 required=12.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,X_MSMAIL_PRIORITY_HIGH, X_PRIORITY_HIGH autolearn=no version=2.64 X-Spam-Level: * I would like to withdraw the Data Access vote for the resolution of Issue 8180 on Ballot 1. This resolution has two problems: 1. The issue relates to the section on ReadLinkObjectEndQualifierAction, which has an empty Semantics subsection. The issue notes that the semantics should be provided or the header delated. The resolution discussion says that: "Header modifications are a duplicate of 8155." However, this isn't really a header issue: the semantics for the action should be provided. 2. Regardless of the above, the Discussion part of the resolution includes a text revision (addressing another part of the issue) that should really be under Revised Text. The issue should then be marked as Resolved, not Duplicate. (The revised text should also be "{subsets Action::output}", per the standard format given in Section 6.5.1 of the spec, not "(Specialized from Action:output)" as given.) Sorry I didn't catch this sooner -- I noticed it when I started working on Issue 8178, which is similar to 8180, but for ReadLinkObjectAction. Subject: RE: DRAFT of ballot 6 Date: Sun, 17 Jul 2005 23:31:54 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRAFT of ballot 6 Thread-Index: AcWLDFwjyVCT4WBHSaSGhlQjAkpekAALdleg From: "Pete Rivett" To: "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com See detailed comments below. I think 8706 needs more work and so should probably be pulled this time round. The discussion for 7967 is contradictory: Oystein says the 'issue is understandable' yet the second comment that 'agrees with Oystein' says the issue should be close due to 'unclear issue formulation'. It cannot be both understandable and unclear! There may be valid reasons to close the issue with no change but this does not seem to be one of them. 8026 seem premature to close - unless Conrad can confirm that he's been convinced. 8028: it seems intuitively wrong to have a constructor dependent on an instance. Also the definition of a constructor as "A constructor is any operation having a single return result parameter of the type of the owning class. " seems over-general. e.g. the Person::getMother() operation returns a Person but is not a constructor by any stretch. Furthermore there are genuine constructors that are not defined on t he owning class (e.g. those owned by factory classes). 8167: Should not be 'closed no change' since it contains a revision to text. 8180: proposes adding "(Specialized from Action:output)" to a property. However there is no such thing as 'specialized from' for a property in UML: it should be subsets. 8508: I disagree with making Model::viewpoint single valued. It both makes a viewpoint mandatory, and is over-restrictive compared with the accompanying text: for example where a model composes two other models (each with different viewpoints it seems reasonable for the containing model's viewpoint to have two values. Restricting the multiplicity in this way seems unnecessary at RTF stage and uncalled for by the issue (which seems to be complaining about the purely textual difference between [0..*] and [*].) 8454 If ObjectNode is not a MultiplicityElement (which seems to be true) then why does it have constraint [2] isUnique=false - since it will not have such a property. However I must admit I cannot make sense of my original issue - sorry. 8593: The preferred style seems to be 'None.' rather than 'No additional associations'. Issue 8706: First para of Discussion is misleading since the mechanism is not based on Import but metamodel/classReference. Need to expand on the practical meaning of 'accessible (visible)' in para 2 of revised text. And the meaning of "the most detailed namespaces " The last clause of this paragraph 2 needs reformulating/punctuating: "only the referenced elements which owned elements are not referenced are filtered (shown) by the profile". As well as not scanning, it seems mistaken in equating 'filtered' (which is normally used in the sense 'filtered out') with '(shown)' Need to say what happens if a normal PackageImport is used by a Profile. In the example I don't see why Metaclass1 is hidden - since it's contained by the Package which is <>d. And why an explicit reference is needed for Metaclass2 when it's owned by the Package. There is clearly something going on that I'm not getting - and I was involved in t he calls on this subject! I think we could do with some OCL to be clear exactly what the set of 'accessible' elements is. Likewise I do not understand the paragraph about combining imports if one Profile imports another. If P1 imports P2 when why combine 'at the P2 level'? Generally there are several typos and the English needs tidying up. 8752: the Issue summary is missing words - it says " instead of " 8759: revised text should refer to "OpaqueAction, Generalizations" not "Actions, Generalizations". 8867: again the final 2 sentences should have 'subsets' not 'specializes'. 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, July 17, 2005 8:55 PM To: uml2-rtf@omg.org Subject: DRAFT of ballot 6 Importance: High Slim pickings this time around -- just 31 resolution proposals. However, with vacation season on us, I guess this is to be expected. It does mean, however, that we will need to pick up our pace. We still have close to 400 issues to deal with. Please look at these carefully and raise any concerns that you have with these proposed resolutions before noon EDT on Friday, July 22. Regards, Bran To: uml2-rtf@omg.org Subject: Feedback on draft of ballot 6 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 18 Jul 2005 11:15:33 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/18/2005 11:15:34, Serialize complete at 07/18/2005 11:15:34 Here is my feedback on the proposed resolutions for ballot 6 (there are so much mechanics in putting together a ballot, that I often do not have time to actually read the proposed resolution texts): 7967: I believe that this is really a recommendation to defer the issue until the simple time model is reworked. (The issue text looks perfectly clear to me and asks for a reasonable generalization that the target of this action should be either a variable or an attribute.) I think that I will pull this proposal until we've had a chance to discuss it further. 8026: Although I dislike the current notation, it is in the adopted spec and should only be eliminated if there is something incorrect about it. This is not the case. The issue text is proposing an alternative, which I do not believe has been explored enough (the discussion is limited to an attack and defense of what is currently there -- this is really not addressing the issue). I am inclined to pull this one as well. 8028: The proposed resolution eliminates the need for one of the variants of the «create» standard stereotype. Therefore, it should also propose removal of the corresponding stereotype (including the reference to it on page 745) 8167: The revised text seems to address a different issue than the one that is in the submission. I think that the different issue should be raised and resolved separately and that this one should simply be a "closed, no change" (I can do this as an editorial fix.) 8180: The form "Specialized from " only appears in the Actions chapter, instead of the standard form "Subsets " used elsewhere. I think that this particular resolution should go in but a separate issue raised that changes all of these non-standard forms to the standard form. 8407: the item that changes "no additional attributes" to "None" should be removed from the resolution (see my previous e-mail) The subsets should follow the standard convention of qualifying the property, thus "subsets ownedElement" should be "subsets Element::ownedElement" The above two changes need to be made also to resolutions to issues 8408, 8409, and 8410 There is a spurrious paragraph beginning with "Depending on the context" which should be removed from the resolution -- although some explanation should be provided for how this part of the issue was resolved. Except for the last item, I will make all the changes to the resolutions above, since they are editorial. 8706: The resolution only provides a fix for the Superstructure -- a fix for the infrastructure should also be added (I can add that as an editorial fix). To summarize, it looks like 7967, 8026, and 8028 will be pulled from the ballot. Two new issues need to be raised related to 8167 and 8180 (I will raise them) and a number of editorial fixes to the proposed texts need to be made. Regards, Bran To: "Pete Rivett" Cc: uml2-rtf@omg.org Subject: RE: DRAFT of ballot 6 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 18 Jul 2005 11:53:29 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/18/2005 11:53:31, Serialize complete at 07/18/2005 11:53:31 Comments on Pete's comments for ballot 6: > I think 8706 needs more work and so should probably be pulled this time round. Since Philippe is not around to defend it, I guess I will pull it. (Also, as I noted earlier, it needs to have an Infra section.) > The discussion for 7967 is contradictory: Oystein says the 'issue is > understandable' yet the second comment that 'agrees with Oystein' > says the issue should be close due to 'unclear issue formulation'. > It cannot be both understandable and unclear! There may be valid > reasons to close the issue with no change but this does not seem to > be one of them. Agreed. > 8026 seem premature to close - unless Conrad can confirm that he's > been convinced. Personally, I think that this is an issue that will require a vote, since I don't think that Conrad will ever be convinced. However, I will pull the issue because I don't think the presentation option proposed by Conrad has been discussed enough. In my view, it can only go as an optional form, since the current form is already in the adopted spec. Although I don't like it myself, it is wrong to argue that the notation is unusable as the example in the document shows. > 8028: it seems intuitively wrong to have a constructor dependent on > an instance. > Also the definition of a constructor as "A constructor is any > operation having a single return result parameter of the type of the > owning class. " seems over-general. e.g. the Person::getMother() > operation returns a Person but is not a constructor by any stretch. > Furthermore there are genuine constructors that are not defined on t > he owning class (e.g. those owned by factory classes). Disagree. We already argued in the past that the meaning of source and destination of a dependency is sometimes ambiguous. It's a problem with the Dependency concept and not with this particular resolution. Nevertheless, I will pull this issue for other reasons, as stated in my comments. > 8167: Should not be 'closed no change' since it contains a revision to text. Will remove the revision and raise an issue for the revision. > 8180: proposes adding "(Specialized from Action:output)" to a > property. However there is no such thing as 'specialized from' for a > property in UML: it should be subsets. Correct. However, I think that this requires a special issue, which I have raised. Leaving this resolution in, in its current (incorrect) form, will at least make the chapter consistent throughout. I have already raised an issue for the more general problem. > 8508: I disagree with making Model::viewpoint single valued. It both > makes a viewpoint mandatory, and is over-restrictive compared with > the accompanying text: for example where a model composes two other > models (each with different viewpoints it seems reasonable for the > containing model's viewpoint to have two values. > Restricting the multiplicity in this way seems unnecessary at RTF > stage and uncalled for by the issue (which seems to be complaining > about the purely textual difference between [0..*] and [*].) I disagree. The spec is pretty clear when it says that a "model captures a view" (note the singular case), which does not remove the possibility of having other models with different views in them. If we allow multiple viewpoints in a single model, then we will not be able to clearly delineate them, since they would all be batched into a single model package. The only question I have here is whether the multiplicity should be [0..1] allowing models that are not committed to any particular viewpoints. This would allow models for specific viewpoints to be grouped into a common viewless model. > 8454 If ObjectNode is not a MultiplicityElement (which seems to be > true) then why does it have constraint [2] isUnique=false - since it > will not have such a property. However I must admit I cannot make > sense of my original issue - sorry. > > 8593: The preferred style seems to be 'None.' rather than 'No > additional associations'. See my previous comments on this. > Issue 8706: First para of Discussion is misleading since the > mechanism is not based on Import but metamodel/classReference. > Need to expand on the practical meaning of 'accessible (visible)' in > para 2 of revised text. And the meaning of "the most detailed namespaces " > The last clause of this paragraph 2 needs reformulating/punctuating: " > only the referenced elements which owned elements are not referenced > are filtered (shown) by the profile". As well as not scanning, it > seems mistaken in equating 'filtered' (which is normally used in the > sense 'filtered out') with '(shown)' > Need to say what happens if a normal PackageImport is used by a Profile. > In the example I don't see why Metaclass1 is hidden - since it's > contained by the Package which is <>d. And why an > explicit reference is needed for Metaclass2 when it's owned by the > Package. There is clearly something going on that I'm not getting - > and I was involved in t he calls on this subject! > I think we could do with some OCL to be clear exactly what the set > of 'accessible' elements is. > Likewise I do not understand the paragraph about combining imports > if one Profile imports another. If P1 imports P2 when why combine > 'at the P2 level'? > Generally there are several typos and the English needs tidying up. Will pull this. > 8752: the Issue summary is missing words - it says " instead > of " I will fix this. > 8759: revised text should refer to "OpaqueAction, Generalizations" > not "Actions, Generalizations". Good eye. I will fix this editorially. > 8867: again the final 2 sentences should have 'subsets' not 'specializes'. See above. Thanks...Bran