Issue 4448: Does visibility apply to creating an destroying links? (uml2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: It isn't clear whether visibility of association ends applies to creating and destroying links. If it does, then what if one end is private and the other public, can the private end create or destroy a link? Resolution: see above Revised Text: In Superstructure, Classes, and in Infrastructure, Core::Abstractions, Visibility package NamedElement Attribute, visibility entry, change description to “Determines where the NamedElement appears within different Namespaces within the overall model, and its accessibility.” Semantics, second paragraph in Superstructure, first paragraph in Infrastructure first sentence, replace “in different namespaces within a model” with “, either in namespaces or in access to the element. second sentence, replace “import and generalization” with “import, generalization, and access”. VisibilityKind, Semantics, first paragraph, replace "and Packages packages" with ", Packages, and Classes packages" in Superstructure, and with “, Packages, and Classifiers packages” in Infrastructure. In Superstructure, Classes, and in Infrastructure, Core::Basic Class, Semantics, at end, add new paragraph: "A class cannot access private features of another class, or protected features on another class that is not its supertype. When creating and deleting associations, at least one end must allow access to the class." In Superstructure, Actions WriteLinkAction, Constraints, add new constraint "The visibility of at least one end must allow access to the class using the action." CreateLinkObjectAction, Semantics, first sentence, after "semantics" add "and constraints". Actions taken: August 3, 2001: received issue August 23, 2006: closed issue Discussion: More time is needed to consider the interaction of visibility with associations, to align it with visibility of properties....The specification inadvertently omitted that visibility constrains access, as well as importation and inheritance. In the particular case of classes, visibility constrains the actions of methods of the class. Creation and destruction of links should be allowed by methods that have access to at least one end of the association. End of Annotations:===== Reply-To: From: "Conrad Bock" To: Cc: "Cris Kobryn" Subject: UML 1.5 issues Date: Fri, 3 Aug 2001 08:57:48 -0700 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Q?+e9Oe%!!h^(!!~DRd9 Juergen, Here are my issues for UML 1.5. These are submitted as comments on the UML 1.4 as specified in ad/2001-02-13. Thanks, Conrad 3) Does visibility apply to creating an destroying links? It isn't clear whether visibility of association ends applies to creating and destroying links. If it does, then what if one end is private and the other public, can the private end create or destroy OMG Issue No: 4448 Title: Does visibility apply to creating an destroying links? Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: It isn't clear whether visibility of association ends applies to creating and destroying links. If it does, then what if one end is private and the other public, can the private end create or destroy a link? Discussion: Visibility is strictly a design-time concept and does not have any direct run-time semantics. Hence, it has no bearing on creating and destroying links. Disposition: Resolved OMG Issue No: 4448 Title: Does visibility apply to creating an destroying links? Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: It isn't clear whether visibility of association ends applies to creating and destroying links. If it does, then what if one end is private and the other public, can the private end create or destroy a link? Discussion: Visibility is strictly a design-time concept and does not have any direct run-time semantics. Hence, it has no bearing on creating and destroying links. Disposition: Resolved Subject: RE: Draft shared issues ballot - Infra Ballot 3 Date: Wed, 9 Jun 2004 10:24:52 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft shared issues ballot - Infra Ballot 3 Thread-Index: AcROOu6bKj8yYVusRKWVMfp4HT3VXQAAKGLwAAKO+OA= From: "Tolbert, Doug M" To: "Pete Rivett" , , , X-OriginalArrivalTime: 09 Jun 2004 17:24:52.0863 (UTC) FILETIME=[ACE5B8F0:01C44E46] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i59HTWun017670 I'd suggest making the choice about whether Infra is included can be made based on whether the Infra document is affected by the proposed change. In one or two of the issues I've examined so far, being marked as 'shared' doesn't necessarily guarantee that both the Super and Infra documents will be affected by a resolution. So, in the interests of speeding resolutions along the pipe, I'd just declare an issue marked as shared but with a resolution that doesn't affect both documents as a categorization error and correct that. This way only one FTF needs to vote on it, not both. Doug -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Wednesday, June 09, 2004 10:16 AM To: conrad.bock@nist.gov; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Draft shared issues ballot - Infra Ballot 3 Hi Conrad, This is not late at all - that's the point of sending out the draft. IMHO these metamodelled actions (CreateLink etc) are just a particular concrete realization of the general ability to create/delete links: it should be part of the general definition of visibility to state how and when the concept should apply. So I think the issue does apply to Infra as well as Super. That leaves your point as to whether the visibility, expressed at design time, should govern runtime actions. I don't have a strong view on this but it seems to me that the whole point of specifying information at design time is to have an effect on the runtime. I guess for visibility the obvious implementation is to reflect it in the visibility modifiers on generated code, however this is a technology-specific option and for programming languages that don't have such modifiers an option would be to forbid operations at 'true' runtime. Having established that principle though, I personally don't think that visibility *should* forbid these runtime operations. So the resolution would, if anything, just add further explanation to the description of Visibility. What does anyone else think? Should I pull the issue this time round? Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Wednesday, June 09, 2004 4:51 PM > To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org > Subject: RE: Draft shared issues ballot - Infra Ballot 3 > > > Pete, > > Sorry for the late input, but looking at issue 4448 (Does visibility > apply to creating an destroying links?) more closely, I think this > should be assigned to super, actions in particular. It's > asking whether > the actions CreateLink and DestroyLink need to pay attention to > visibility. Since these actions are part of the model, ie, > design time, > I think visibility would apply. > > Conrad > Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft shared issues ballot - Infra Ballot 3 Date: Wed, 9 Jun 2004 15:04:14 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Pete, > That leaves your point as to whether the visibility, expressed at design > time, should govern runtime actions. The actions, as metamodel instances, exist at design time. For example, the ReadStructuralFeatureAction metaclass cannot be instantiated and used in an instance of Activity in a way that violates the visbility of the structural feature being read (see constraint 4 of StructuralFeatureAction). I filed the issue about Create/DestroyLink because I figured the same might apply to those. > IMHO these metamodelled actions (CreateLink etc) are just a particular > concrete realization of the general ability to create/delete links: it > should be part of the general definition of visibility to state how and > when the concept should apply. So I think the issue does apply to Infra > as well as Super. Sure, but the actions are just supposed to reflect the general semantics given in infra/classes. I'd just as soon move this to super/actions, or at least pull it for next round. Thanks, Conrad To: "Pete Rivett" Cc: conrad.bock@nist.gov, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft shared issues ballot - Infra Ballot 3 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Stephen Brodsky Date: Wed, 9 Jun 2004 12:28:12 -0700 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 6.0.2CF2HF303 | April 20, 2004) at 06/09/2004 13:28:17, Serialize complete at 06/09/2004 13:28:17 Pete, Users of a reflective API probably would not expect visibility to change the behavior because the purpose of visibility is to scope access based on the caller and that is often only well handled at the programming interface declaration level. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Pete Rivett" 06/09/2004 10:15 AM To: , , cc: Subject: RE: Draft shared issues ballot - Infra Ballot 3 Hi Conrad, This is not late at all - that's the point of sending out the draft. IMHO these metamodelled actions (CreateLink etc) are just a particular concrete realization of the general ability to create/delete links: it should be part of the general definition of visibility to state how and when the concept should apply. So I think the issue does apply to Infra as well as Super. That leaves your point as to whether the visibility, expressed at design time, should govern runtime actions. I don't have a strong view on this but it seems to me that the whole point of specifying information at design time is to have an effect on the runtime. I guess for visibility the obvious implementation is to reflect it in the visibility modifiers on generated code, however this is a technology-specific option and for programming languages that don't have such modifiers an option would be to forbid operations at 'true' runtime. Having established that principle though, I personally don't think that visibility *should* forbid these runtime operations. So the resolution would, if anything, just add further explanation to the description of Visibility. What does anyone else think? Should I pull the issue this time round? Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Wednesday, June 09, 2004 4:51 PM > To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org > Subject: RE: Draft shared issues ballot - Infra Ballot 3 > > > Pete, > > Sorry for the late input, but looking at issue 4448 (Does visibility > apply to creating an destroying links?) more closely, I think this > should be assigned to super, actions in particular. It's > asking whether > the actions CreateLink and DestroyLink need to pay attention to > visibility. Since these actions are part of the model, ie, > design time, > I think visibility would apply. > > Conrad > To: Stephen Brodsky Cc: conrad.bock@nist.gov, mu2i-ftf@omg.org, "Pete Rivett" , uml2-superstructure-ftf@omg.org Subject: RE: Draft shared issues ballot - Infra Ballot 3 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Wed, 9 Jun 2004 15:46:53 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF262 | May 19, 2004) at 06/09/2004 16:46:55, Serialize complete at 06/09/2004 16:46:55 I have always thought of visibility as a software engineering concept, not a semantic concept. That is, its purpose is to prevent humans from structuring programs in a way that makes them difficult to modify. By making something private, you prevent models/specifications/code in other classes from taking advantage of it and thereby locking a design decision into the implementation that is difficult to reverse. Therefore visibility needs to act at modeling/compile time. It should NOT be a run-time property. If some code (model, whatever, don't quibble with me over the words) gets by the compiler (modeling tool, whatever) and makes it to run time, the last thing you want is to generate an error. The purpose of visibility was to prevent writing the code in the first place. If it nevertheless got written and compiled, it would make matters worse to stop it on bureaucratic grounds. (Visibility is fundamentally a bureaucratic property.) A compile (code generator, whatever) could certainly look at visibility AND look at the actions someone has used in a model and decide that the actions are not legitimate because they violate the visibility constraints. But that does NOT make them run-time properties and does NOT affect the semantics of the actions. It should NOT be in infrastructure at all. Software engineering properties belong in superstructure. Infrastructure should just handle semantics, not get into stating restrictons of this kind. You should definitely pull this proposal from the ballot. Leave visibility alone as a model-time and software engineering property, not a semantic and run-time property. - Jim Rumbaugh Stephen Brodsky/Santa Teresa/IBM@IBMUS wrote on 06/09/2004 12:28:12 PM: > > Pete, > > Users of a reflective API probably would not expect visibility to > change the behavior because the purpose of visibility is to scope > access based on the caller and that is often only well handled at > the programming interface declaration level. > > Thanks, > > -Steve > > Stephen A. Brodsky, Ph.D. > Software Architect, STSM > Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS > Internet Address: sbrodsky@us.ibm.com > Phone: 408.463.5659 > > > "Pete Rivett" > 06/09/2004 10:15 AM > > > To: , , > > cc: > Subject: RE: Draft shared issues ballot - Infra Ballot 3 > > > > > Hi Conrad, > This is not late at all - that's the point of sending out the draft. > IMHO these metamodelled actions (CreateLink etc) are just a particular > concrete realization of the general ability to create/delete links: it > should be part of the general definition of visibility to state how and > when the concept should apply. So I think the issue does apply to Infra > as well as Super. > > That leaves your point as to whether the visibility, expressed at design > time, should govern runtime actions. I don't have a strong view on this > but it seems to me that the whole point of specifying information at > design time is to have an effect on the runtime. I guess for visibility > the obvious implementation is to reflect it in the visibility modifiers > on generated code, however this is a technology-specific option and for > programming languages that don't have such modifiers an option would be > to forbid operations at 'true' runtime. Having established that > principle though, I personally don't think that visibility *should* > forbid these runtime operations. So the resolution would, if anything, > just add further explanation to the description of Visibility. > > What does anyone else think? Should I pull the issue this time round? > > Pete > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > Chief Scientist, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > -----Original Message----- > > From: Conrad Bock [mailto:conrad.bock@nist.gov] > > Sent: Wednesday, June 09, 2004 4:51 PM > > To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org > > Subject: RE: Draft shared issues ballot - Infra Ballot 3 > > > > > > Pete, > > > > Sorry for the late input, but looking at issue 4448 (Does visibility > > apply to creating an destroying links?) more closely, I think this > > should be assigned to super, actions in particular. It's > > asking whether > > the actions CreateLink and DestroyLink need to pay attention to > > visibility. Since these actions are part of the model, ie, > > design time, > > I think visibility would apply. > > > > Conrad > > OMG Issue No: 4448 Title: Does visibility apply to creating an destroying links? Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: It isn't clear whether visibility of association ends applies to creating and destroying links. If it does, then what if one end is private and the other public, can the private end create or destroy a link? Discussion: Visibility is strictly a design-time concept and does not have any direct run-time semantics. Hence, it has no bearing on creating and destroying links. Disposition: Closed, no change Reply-To: From: "Conrad Bock" To: , Subject: RE: More resolutions for Ballot 19 from Bran Date: Wed, 14 Jul 2004 16:34:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Some comments on your ballot 19 resolutions. Conrad - Issue 2582 (class EnumerationLiteral issue) A data types could be a struct that points to objects, so I don't think the constraint is correct. In any case, it isn't what the issue is about. - Issue 3391 (Multiple languages for uninterpreted strings) The issue is asking for the various body/language string attributes to support multiple languages, for example by both being multi-valued and ordered. The resolution addresses a different issue. - Issue 4448 (Does visibility apply to creating an destroying links?) Agreed, visibility is a design-time concept, but so are actions, ie, they exist in the model. The purpose of visibility is to constrain models not to specify actions that violate it. For example, if an attribute is private, there shouldn't be a ReadStructuralFeature action in a method of another object that access the private attribute. Since links can affect objects in UML 2, the issue asks if visibility applies to manipulating them To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: More resolutions for Ballot 19 from Bran X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 14 Jul 2004 22:29:55 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/14/2004 22:29:59, Serialize complete at 07/14/2004 22:29:59 Thanks, Conrad for reviewing these. Some responses and some questions embedded below: > - Issue 2582 (class EnumerationLiteral issue) > > A data types could be a struct that points to objects, so I don't > think the constraint is correct. In any case, it isn't what the > issue is about. A pointer to an object (Instancevalue) is still a kind of DataType, so the constraint still looks valid to me. I agree that the issue was not about that directly, but I thought it useful to add that constraint, because it is implicit in the issue. Alternatively, I can take the constraint out and close the issue "No change". What do you think? > - Issue 3391 (Multiple languages for uninterpreted strings) > > The issue is asking for the various body/language string > attributes to support multiple languages, for example by both > being multi-valued and ordered. The resolution addresses a > different issue. That's not how I read it, but since you raised the issue, I am sure you know what you meant. What resolution do you propose? > - Issue 4448 (Does visibility apply to creating an destroying links?) > > Agreed, visibility is a design-time concept, but so are actions, > ie, they exist in the model. The purpose of visibility is to > constrain models not to specify actions that violate it. For > example, if an attribute is private, there shouldn't be a > ReadStructuralFeature action in a method of another object that > access the private attribute. Since links can affect objects in > UML 2, the issue asks if visibility applies to manipulating them > also. And, the answer is that it does not -- perhaps I should make that clearer. You seem to be implying some kind of capability mechanism that keeps visibility information around at run time. I think that this is assuming too much. Thanks again....Bran Reply-To: From: "Conrad Bock" To: , Subject: RE: More resolutions for Ballot 19 from Bran Date: Thu, 15 Jul 2004 15:44:26 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Followup discussion below, Conrad > > - Issue 2582 (class EnumerationLiteral issue) > > A data types could be a struct that points to objects, so I don't > > think the constraint is correct. In any case, it isn't what > > the issue is about. > A pointer to an object (Instancevalue) is still a kind of DataType, > so the constraint still looks valid to me. OK, that makes sense. > What do you think? > > > - Issue 3391 (Multiple languages for uninterpreted strings) > > > > The issue is asking for the various body/language string > > attributes to support multiple languages, for example by both > > being multi-valued and ordered. The resolution addresses a > > different issue. > > That's not how I read it, but since you raised the issue, I am > sure you know what you meant. What resolution do you propose? I think the various places that have body/language attributes should be: body : String [1..*] {ordered} language : String [0..*] {ordered} So multiple strings can be specified in multiple languages. The body and language strings would be matched by order. > > - Issue 4448 (Does visibility apply to creating an destroying links?) > > > > Agreed, visibility is a design-time concept, but so are actions, > > ie, they exist in the model. The purpose of visibility is to > > constrain models not to specify actions that violate it. For > > example, if an attribute is private, there shouldn't be a > > ReadStructuralFeature action in a method of another object that > > access the private attribute. Since links can affect objects in > > UML 2, the issue asks if visibility applies to manipulating them > > also. > And, the answer is that it does not -- perhaps I should make > that clearer. You seem to be implying some kind of capability > mechanism that keeps visibility information around at run time. > I think that this is assuming too much. Visibility only applies to design time, as you said, we're in agreeement on that. I'm saying design time is when actions are created, ie, when the metaclass CreateLinkAction is instantiated, etc. Visibility applies to where those instances of CreateLinkAction, etc, can be put. For example, an instance of ReadStructuralFeatureAction for a private attribute cannot be put in an activity used as a method for a class other than the one on which the attribute is declared. Visibility is a well-formedness rule on user-level models. I personally think if ReadStructuralFeatureAction must obey visibility, as it does curerently, that CreateLinkAction should, at least in the To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 19 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 16 Jul 2004 14:35:53 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/16/2004 14:35:55, Serialize complete at 07/16/2004 14:35:55 Will amend resolution text as suggested. Bran "Conrad Bock" 07/16/2004 02:16 PM Please respond to conrad.bock To , cc Subject RE: Draft of ballot 19 Bran, Comments on draft 19, thanks, Conrad - 4448 (Does visibility apply to creating an destroying links?) Fine with me to defer, but could it reflect my comments earlier? The issue does not ask for design time concepts to be applied at runtime, as the resolution currently says. Proposed deferral text: "More time is needed to consider the interaction of visibility with associations, to align it with visibility of properties". To: uml2-rtf@omg.org Subject: Issue 4448 on ballot 8: please take note! X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Sun, 21 Aug 2005 15:45:35 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/21/2005 15:45:38, Serialize complete at 08/21/2005 15:45:38 The proposed resolution to issue 4448 that is included in the current ballot (ballot 8) includes an interpretation of the semantics of visibility. So, please take care when you vote on this issues, since the vote will, in effect, determine the future interpretation of this concept. By voting YES or NO to this resolution, you will be voting for the interpretation stated therein or against it. This has been a long-standing debate in the UML community and time has come to resolve it. I feel that we might as well do it now. We are clearly running out of time in this RTF and prolonging this debate in the remote hope of reaching some consensus is no longer productive. Ed has recently posted a set of rather erudite discussions related to the meaning of visibility that you may want to consult before reaching your decision. Cheers, Bran From: "Ed Seidewitz" To: Subject: RE: Issue 4448 on ballot 8: please take note! Date: Mon, 22 Aug 2005 19:33:01 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWmiPSiGae99N2hQ5KiOqIW9hpEgAA5gHww For the convenience of future discussion, here is the bottom line of my erudition on this topic. Resolution 4448 asks for a clarification of the relevance of the visibility of the ends of an association on the creation and destruction of links of that association. The following are clarifications per ptc/04-10-02. 1. If the link is created using a CreateObjectAction and then a WriteStructuralFeatureAction on a Property that is one of the association ends, or destroyed using a ReadStructuralFeatureAction and then a DestroyObjectAction, visibility constraints apply to the StructuralFeatureActions (see Constraint [4] of StructuralFeatureAction). Any model that violates these constraints is statically ill-formed. 2. If the link is created/destroyed using a Create/DestroyLinkAction, then there are no static or dynamic visibility constraints specified in the standard. Any tool which enforces such constraints is not conformant with the standard as currently written. 3. In neither of the above cases is it necessary to import the association ends in order to reference them in the actions (i.e., "fully qualified" names can be used), so visibility restrictions on import are not particularly relevant here. If the above is not the desired behavior, then a change needs to be proposed (i.e., to enforce visibility restrictions in case 2, for example). But, even if the above behavior is what is desired, and the issue can be closed with no change, I do not believe the discussion in the resolution as currently written provides a correct analysis of the situation. The issue as written does not ask at all about the "run time" nature of visibility, only about whether visibility (which is usually understood in a static sense) constrains the ability to specify actions to create and destroy links. Such visibility constraints are clearly relevant to the mechanisms of link creation and destruction, as indicated in above. -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Sunday, August 21, 2005 3:46 PM To: uml2-rtf@omg.org Subject: Issue 4448 on ballot 8: please take note! The proposed resolution to issue 4448 that is included in the current ballot (ballot 8) includes an interpretation of the semantics of visibility. So, please take care when you vote on this issues, since the vote will, in effect, determine the future interpretation of this concept. By voting YES or NO to this resolution, you will be voting for the interpretation stated therein or against it. This has been a long-standing debate in the UML community and time has come to resolve it. I feel that we might as well do it now. We are clearly running out of time in this RTF and prolonging this debate in the remote hope of reaching some consensus is no longer productive. Ed has recently posted a set of rather erudite discussions related to the meaning of visibility that you may want to consult before reaching your decision. Cheers, Bran From: "Ed Seidewitz" To: Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 11:13:23 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWn4hI3GiU7NZANSySv6jgW5lKPygAESFaw Bran -- I agree that we will have no resolution on run-time vs. compile-time debates. I just don't think this is particularly relevant to issue 4448. That is why I, personally, disagree with your wording of the resolution, and why I think voting on it is premature. The complete text of issue 4448: "It isn't clear whether visibility of association ends applies to creating and destroying links. If it does, then what if one end is private and the other public, can the private end create or destroy a link?" This doesn't ask anything about "handles" or for any new sort of run-time visibility mechanism. I would re-word it, more verbosely, but perhaps more clearly, as follows. "Is it allowed to have an action to create or destroy a link if the action does not have visibility to all the association ends of the association of the link?" The answer is 1. If you use a Create/DestroyObjectAction and then use a Read/WriteStructuralFeatureAction, then the StructuralFeatureAction must have static visibility to the association end being read/written. 2. If you use a Create/DestroyLinkAction, then there is no (static or dynamic) visibility restriction. Any or all the association ends can be marked as private in their namespace, and the LinkAction is still legal, whether or not it is attached to the same namespace. OK, now I have repeated myself a few times on this, so that's probably enough. If you or Conrad would like me to write this up as a new proposed resolution for issue 4448, I will. Otherwise, I'll wait for a ballot vote on the issue. -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 23, 2005 8:56 AM To: conrad.bock@nist.gov Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! > > This has been a long-standing debate in the UML community and > > time has come to resolve it. > > I don't recall this. Was it in the FTF? It was fist debated for a long time in the U2P and then in the FTF. I distinctly recall the run-time vs compile-time debates on this point and the fact that we could just not reach consensus. As a matter of policy: I think it is a lot fairer to have a vote on an issue quickly after all the positions have been stated at least once clearly. The alternative of dragging on a discussion until the majority of voting members no longer care and simply want the debate to stop, no matter what the resolution, is not a good way to run things. This has happened before and I want to avoid it. > Those addressed the runtime/compile time problems in the resolution, but > I posted on what I thought was the central issue, see below. > > To those voting: The current resolution would mean that methods on one > object can invoke private methods on another, or modify private > properties on another. In the general case, this is not possible. Unless you have a reflective system and malicious code, you will not be able to obtain a handle on any of these things, since access to those handles are controlled by static visibility rules. For example, if a private method is not visible at compile time, then even if you get a handle on the object that has such private features, you will generally not be able to access them. As for malicious code, visibility restrictions are easily circumvented anyways. Bran To: "Ed Seidewitz" Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 23 Aug 2005 11:55:35 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/23/2005 11:55:50, Serialize complete at 08/23/2005 11:55:50 Thanks, Ed. Actually, I agree with your summary. Please provide a wording of the resolution that you think appropriate. Bran "Ed Seidewitz" 08/23/2005 11:13 AM To cc Subject RE: Issue 4448 on ballot 8: please take note! Bran -- I agree that we will have no resolution on run-time vs. compile-time debates. I just don't think this is particularly relevant to issue 4448. That is why I, personally, disagree with your wording of the resolution, and why I think voting on it is premature. The complete text of issue 4448: "It isn't clear whether visibility of association ends applies to creating and destroying links. If it does, then what if one end is private and the other public, can the private end create or destroy a link?" This doesn't ask anything about "handles" or for any new sort of run-time visibility mechanism. I would re-word it, more verbosely, but perhaps more clearly, as follows. "Is it allowed to have an action to create or destroy a link if the action does not have visibility to all the association ends of the association of the link?" The answer is 1. If you use a Create/DestroyObjectAction and then use a Read/WriteStructuralFeatureAction, then the StructuralFeatureAction must have static visibility to the association end being read/written. 2. If you use a Create/DestroyLinkAction, then there is no (static or dynamic) visibility restriction. Any or all the association ends can be marked as private in their namespace, and the LinkAction is still legal, whether or not it is attached to the same namespace. OK, now I have repeated myself a few times on this, so that's probably enough. If you or Conrad would like me to write this up as a new proposed resolution for issue 4448, I will. Otherwise, I'll wait for a ballot vote on the issue. -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 23, 2005 8:56 AM To: conrad.bock@nist.gov Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! > > This has been a long-standing debate in the UML community and > > time has come to resolve it. > > I don't recall this. Was it in the FTF? It was fist debated for a long time in the U2P and then in the FTF. I distinctly recall the run-time vs compile-time debates on this point and the fact that we could just not reach consensus. As a matter of policy: I think it is a lot fairer to have a vote on an issue quickly after all the positions have been stated at least once clearly. The alternative of dragging on a discussion until the majority of voting members no longer care and simply want the debate to stop, no matter what the resolution, is not a good way to run things. This has happened before and I want to avoid it. > Those addressed the runtime/compile time problems in the resolution, but > I posted on what I thought was the central issue, see below. > > To those voting: The current resolution would mean that methods on one > object can invoke private methods on another, or modify private > properties on another. In the general case, this is not possible. Unless you have a reflective system and malicious code, you will not be able to obtain a handle on any of these things, since access to those handles are controlled by static visibility rules. For example, if a private method is not visible at compile time, then even if you get a handle on the object that has such private features, you will generally not be able to access them. As for malicious code, visibility restrictions are easily circumvented anyways. Bran From: "Ed Seidewitz" To: Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 13:32:07 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWn+0I/TjqqU/1WQxSaxyyHoj7yWAADKDHw Here is my proposed wording for the resolution for Issue 4448. I have left the disposition as "Closed, no change". I think that Conrad might want to propose the lack of a visibility constraint for LinkActions, but I will let him say whether that is the case or not. I have a vague recollection that there was a specific reason for not requiring visibility for LinkActions, but I can't remember any details. -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 23, 2005 11:56 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! Thanks, Ed. Actually, I agree with your summary. Please provide a wording of the resolution that you think appropriate. Bran "Ed Seidewitz" 08/23/2005 11:13 AM To cc Subject RE: Issue 4448 on ballot 8: please take note! Bran -- I agree that we will have no resolution on run-time vs. compile-time debates. I just don't think this is particularly relevant to issue 4448. That is why I, personally, disagree with your wording of the resolution, and why I think voting on it is premature. The complete text of issue 4448: "It isn't clear whether visibility of association ends applies to creating and destroying links. If it does, then what if one end is private and the other public, can the private end create or destroy a link?" This doesn't ask anything about "handles" or for any new sort of run-time visibility mechanism. I would re-word it, more verbosely, but perhaps more clearly, as follows. "Is it allowed to have an action to create or destroy a link if the action does not have visibility to all the association ends of the association of the link?" The answer is 1. If you use a Create/DestroyObjectAction and then use a Read/WriteStructuralFeatureAction, then the StructuralFeatureAction must have static visibility to the association end being read/written. 2. If you use a Create/DestroyLinkAction, then there is no (static or dynamic) visibility restriction. Any or all the association ends can be marked as private in their namespace, and the LinkAction is still legal, whether or not it is attached to the same namespace. OK, now I have repeated myself a few times on this, so that's probably enough. If you or Conrad would like me to write this up as a new proposed resolution for issue 4448, I will. Otherwise, I'll wait for a ballot vote on the issue. -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 23, 2005 8:56 AM To: conrad.bock@nist.gov Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! > > This has been a long-standing debate in the UML community and > > time has come to resolve it. > > I don't recall this. Was it in the FTF? It was fist debated for a long time in the U2P and then in the FTF. I distinctly recall the run-time vs compile-time debates on this point and the fact that we could just not reach consensus. As a matter of policy: I think it is a lot fairer to have a vote on an issue quickly after all the positions have been stated at least once clearly. The alternative of dragging on a discussion until the majority of voting members no longer care and simply want the debate to stop, no matter what the resolution, is not a good way to run things. This has happened before and I want to avoid it. > Those addressed the runtime/compile time problems in the resolution, but > I posted on what I thought was the central issue, see below. > > To those voting: The current resolution would mean that methods on one > object can invoke private methods on another, or modify private > properties on another. In the general case, this is not possible. Unless you have a reflective system and malicious code, you will not be able to obtain a handle on any of these things, since access to those handles are controlled by static visibility rules. For example, if a private method is not visible at compile time, then even if you get a handle on the object that has such private features, you will generally not be able to access them. As for malicious code, visibility restrictions are easily circumvented anyways. Bran UML 2.0 Resolutions 050823 Issue 4448.doc Reply-To: From: "Conrad Bock" To: "Ed Seidewitz" , Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 16:21:18 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Ed, I happen to disagree with your proposal, will send comments separately, but Bran brought up another more fundamental point, that the definition of visibility as access control is not in the classes chapter, where visibility is introduced. Classes only says: ElementImport visibility: VisibilityKind Specifies the visibility of the imported PackageableElement within the importing Package. NamedElement visibility: VisibilityKind [0..1] Determines the visibility of the NamedElement within different Namespaces within the overall model. Semantics: The visibility attribute provides the means to constrain the usage of a named element in different namespaces within a model. It is intended for use in conjunction with import and generalization mechanisms. I can't find anywhere in Classes that says visibility is an access restriction to operation calls and property/association modification/creation, etc, even though that is obviously one of its primary uses. Can you? So I would expect a resolution on this to define this aspect of visibility. It seems like there need to be two updates, first to NamedElement, to remove the circular definition, and add some general reference to access control; NamedElement visibility: VisibilityKind [0..1] Determines *where the NamedElement appears* within different Namespaces within the overall model, and it accessibility. Semantics: The visibility attribute provides the means to constrain the usage of a named element, either in terms of access or in namespaces. and giving the specific meaning of "access" in the case of classes: Class Semantics At end add paragraph: "Methods on a class cannot access private features of another class, or protected features on another class that is not its supertype." [CB: Plus wording we can agree on regarding associations.] VisibilityKind Semantics Amend first sentence to: VisibilityKind is intended for use in the specification of visibility in conjunction with, for example, the Imports, Generalizations, Packages, and Classes packages. [ CB: Are those packages in Superstructure? ] We can file another issue that if actions do not conform to this. Conrad Reply-To: From: "Conrad Bock" To: "Ed Seidewitz" , Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 16:36:46 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Ed, Comments on your proposal. Conrad > There are two ways to model the behavior of creating or destroying a > link. > 1. If the link is for a binary association, one of whose ends is owned > by the class at that end, then the link can be created or destroyed by a > using a WriteStructuralFeatureAction on that end. Constraint [4] of the > parent StructuralFeatureAction class requires the action to have > visibility of the StructuralFeature being written to. This is a > statically checkable model constraint, and any model that violates it is > ill-formed. We might want to point out that the semantics of StructuralFeatureAction and LinkActions were made equivalent or association end properties by issue 6143 in the FTF. > 2. A link may also be created using a CreateLinkAction or destroyed > using a DestroyLinkAction. These actions require that the link to be > created or destroyed be identified by giving LinkEndData for all the > association ends of the association of the link. There are no visibility > constraints (static or dynamic) on the references to the association > ends by these actions. Sure, but the point of the issue is to justify this. It seems unintuitive that an object can create links for associations that have private property ends on other classes. From: "Ed Seidewitz" To: Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 17:01:00 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5Q Conrad -- > > 2. A link may also be created using a CreateLinkAction or destroyed > > using a DestroyLinkAction. These actions require that the > link to be > > created or destroyed be identified by giving LinkEndData > for all the > > association ends of the association of the link. There are > no visibility > > constraints (static or dynamic) on the references to the > association > > ends by these actions. > > Sure, but the point of the issue is to justify this. It seems > unintuitive that an object can create links for associations that have > private property ends on other classes. Well, the issue actually just asks for a clarification, not a justification! In any case, though, I do agree that not enforcing visibility for LinkActions is unintuitive and probably unintended. Agreed. Unless someone remembers a specific justification for not having visibility constraints on LinkActions, I would not be adverse to adding them. The constraint could probably be added to LinkEndData and apply to all LinkActions. -- Ed Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 14:08:49 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 4448 on ballot 8: please take note! Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5QAABOFtA= From: "Mellor, Stephen" To: "Ed Seidewitz" , X-OriginalArrivalTime: 23 Aug 2005 21:08:28.0876 (UTC) FILETIME=[CF38D8C0:01C5A826] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j7NLPghh009507 There is no need for visibility constraints on link/unlink: The association is right there in front you! OTOH, we could conflate visibitility in this context with navigability. More precisely, that part of the several elements of the definition of navigability that equate to the concept of visibility. -- stephen > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] > Sent: 2005-08-23, Tuesday 14:01 > To: uml2-rtf@omg.org > Subject: RE: Issue 4448 on ballot 8: please take note! > > Conrad -- > > > > 2. A link may also be created using a CreateLinkAction > or destroyed > > > using a DestroyLinkAction. These actions require that the > > link to be > > > created or destroyed be identified by giving LinkEndData > > for all the > > > association ends of the association of the link. There are > > no visibility > > > constraints (static or dynamic) on the references to the > > association > > > ends by these actions. > > > > Sure, but the point of the issue is to justify this. It seems > > unintuitive that an object can create links for > associations that have > > private property ends on other classes. > > Well, the issue actually just asks for a clarification, not a > justification! > In any case, though, I do agree that not enforcing visibility for > LinkActions is unintuitive and probably unintended. > > Agreed. Unless someone remembers a specific justification for > not having > visibility constraints on LinkActions, I would not be adverse > to adding > them. The constraint could probably be added to LinkEndData > and apply to all > LinkActions. > > -- Ed > > > To: "Ed Seidewitz" Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 23 Aug 2005 17:23:48 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/23/2005 17:23:52, Serialize complete at 08/23/2005 17:23:52 > Agreed. Unless someone remembers a specific justification for not having > visibility constraints on LinkActions, I would not be adverse to adding > them. The constraint could probably be added to LinkEndData and apply to all > LinkActions. Well, take "package" visibility as an example. If I remember right, this means that items with this visibility have only visibility to elements in the package where that item is defined. It sounds to me as if this implies keeping complex tables around identifying who can see what in which object. This is precisely the thing that I was trying to avoid when I objected to the notion of visibility information being retained at run time (apologies to Ed for using this term). Am I misreading this? Bran From: "Ed Seidewitz" To: "'Mellor, Stephen'" , Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 17:24:29 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5QAABOFtAAAFARAA== Steve -- > There is no need for visibility constraints on link/unlink: > The association is right there in front you! Well, if "you" are the modeler, then everything is right there in front of you! If "you" are a class, however, then the whole point of visibility annotations is to restrict what "you" can see in other classes. Remember, we are not discussing the visibility of the association, but the visibility of its ends, which can be owned by (and hence in the namespace of) the classes of those ends. It is thus possible (believe it or not) to have visibility to the associations, but not its ends! Suppose that association R has two association ends, x and y. Suppose that class A owns end x and class B owns end y and, further, declares y to be private. Suppose there is a behavior attached to class A that includes a create link zction for association R. Should this be legal, even though it will result in a change to the value of y, which is a property declared to be private to B? Right now it is. On the other hand, it would not be legal for a WriteStructuralFeatureAction in the context of class A to write to the private property y in class B. -- Ed From: "Ed Seidewitz" To: "'Branislav Selic'" Cc: Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 17:33:54 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWoKQKPWKRJOP7aRGOGYCetDV7DZwAADF4Q Bran -- Yes, I think you are misreading it. And I am not just being pedantic on objecting to the use of the term "run time". I think using this term is what is misleading you. There is nothing involving dynamics or run-time semantics at all in what I am discussing with Conrad. We are talking about whether or not there should be a statically-checkable visibility constraint for link actions, like there already is for structural feature actions. (At least that is all I am talking about.) This really is the traditional meaning of visibility. If you are writing the method of one class, you can't access the private properties of another class. To require this in UML 2, you have to put in the well-formedness constraints to enforce it whenever a property may be referenced (like in a number of the actions). -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 23, 2005 5:24 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! > Agreed. Unless someone remembers a specific justification for not having > visibility constraints on LinkActions, I would not be adverse to adding > them. The constraint could probably be added to LinkEndData and apply to all > LinkActions. Well, take "package" visibility as an example. If I remember right, this means that items with this visibility have only visibility to elements in the package where that item is defined. It sounds to me as if this implies keeping complex tables around identifying who can see what in which object. This is precisely the thing that I was trying to avoid when I objected to the notion of visibility information being retained at run time (apologies to Ed for using this term). Am I misreading this? Bran To: "Ed Seidewitz" Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 23 Aug 2005 17:41:09 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/23/2005 17:41:14, Serialize complete at 08/23/2005 17:41:14 Actually, I AM arguing for a static definition of visibility -- that is what I tried to say in my draft resolution. The concern that I have with what Conrad wants is that it requires a dynamic manifestation. Bran "Ed Seidewitz" 08/23/2005 05:33 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Issue 4448 on ballot 8: please take note! Bran -- Yes, I think you are misreading it. And I am not just being pedantic on objecting to the use of the term "run time". I think using this term is what is misleading you. There is nothing involving dynamics or run-time semantics at all in what I am discussing with Conrad. We are talking about whether or not there should be a statically-checkable visibility constraint for link actions, like there already is for structural feature actions. (At least that is all I am talking about.) This really is the traditional meaning of visibility. If you are writing the method of one class, you can't access the private properties of another class. To require this in UML 2, you have to put in the well-formedness constraints to enforce it whenever a property may be referenced (like in a number of the actions). -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 23, 2005 5:24 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! > Agreed. Unless someone remembers a specific justification for not having > visibility constraints on LinkActions, I would not be adverse to adding > them. The constraint could probably be added to LinkEndData and apply to all > LinkActions. Well, take "package" visibility as an example. If I remember right, this means that items with this visibility have only visibility to elements in the package where that item is defined. It sounds to me as if this implies keeping complex tables around identifying who can see what in which object. This is precisely the thing that I was trying to avoid when I objected to the notion of visibility information being retained at run time (apologies to Ed for using this term). Am I misreading this? Bran Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 14:45:52 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 4448 on ballot 8: please take note! Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5QAABOFtAAAFARAAABCFrg From: "Mellor, Stephen" To: "Ed Seidewitz" , X-OriginalArrivalTime: 23 Aug 2005 21:45:32.0002 (UTC) FILETIME=[FC4EF420:01C5A82B] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j7NM2ihh009938 Which is why I said: >OTOH, we could conflate visibitility in this context with navigability. > More precisely, that part of the several elements of the definition of > navigability that equate to the concept of visibility. -- stephen > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] > Sent: 2005-08-23, Tuesday 14:24 > To: Mellor, Stephen; uml2-rtf@omg.org > Subject: RE: Issue 4448 on ballot 8: please take note! > > Steve -- > > > There is no need for visibility constraints on link/unlink: > > The association is right there in front you! > > Well, if "you" are the modeler, then everything is right > there in front of > you! If "you" are a class, however, then the whole point of visibility > annotations is to restrict what "you" can see in other classes. > > Remember, we are not discussing the visibility of the > association, but the > visibility of its ends, which can be owned by (and hence in > the namespace > of) the classes of those ends. It is thus possible (believe > it or not) to > have visibility to the associations, but not its ends! > > Suppose that association R has two association ends, x and y. > Suppose that > class A owns end x and class B owns end y and, further, > declares y to be > private. Suppose there is a behavior attached to class A that > includes a > create link zction for association R. Should this be legal, > even though it > will result in a change to the value of y, which is a > property declared to > be private to B? Right now it is. On the other hand, it would > not be legal > for a WriteStructuralFeatureAction in the context of class A > to write to the > private property y in class B. > > -- Ed > > > From: "Ed Seidewitz" To: "'Branislav Selic'" Cc: Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 17:52:01 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWoK25ygUT0iFEpRzCfN4BKAWh+ZwAAELWw Bran -- I don't believe that Conrad is arguing for a dynamic manifestation. He is only saying that visibility constraints apply to actions that reference the properties of other classes. Which is statically checkable and is really the whole reason for visibility annotations in the first place. Your original response to the resolution said that visibility was primarily for namespace element import. But, in UML 2, element import is really just about naming -- expanding the names available in one namespace with names from another namespace, possibly aliased. This just doesn't matter for specifying the visibility restrictions on actions, since, e.g., StructuralFeatureAction doesn't identify which structural feature to be modified by name -- it has a direct metaassociation to StructuralFeature. (Conrad has a separate message on why some of the text you quoted from the section on Namespace is misleading -- and I tend to agree with him on this.) Constraint [4] on StructuralFeatureAction is the very thing that gives meaning to "private", "protected" and "public" visibility. The (static) semantics of this is clear. The only question is whether it would be consistent to have a similar constraint on LinkEndData, which has a direct metaassociation to Property (a kind of StructuralFeature). -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 23, 2005 5:41 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! Actually, I AM arguing for a static definition of visibility -- that is what I tried to say in my draft resolution. The concern that I have with what Conrad wants is that it requires a dynamic manifestation. Bran "Ed Seidewitz" 08/23/2005 05:33 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Issue 4448 on ballot 8: please take note! Bran -- Yes, I think you are misreading it. And I am not just being pedantic on objecting to the use of the term "run time". I think using this term is what is misleading you. There is nothing involving dynamics or run-time semantics at all in what I am discussing with Conrad. We are talking about whether or not there should be a statically-checkable visibility constraint for link actions, like there already is for structural feature actions. (At least that is all I am talking about.) This really is the traditional meaning of visibility. If you are writing the method of one class, you can't access the private properties of another class. To require this in UML 2, you have to put in the well-formedness constraints to enforce it whenever a property may be referenced (like in a number of the actions). -- Ed -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 23, 2005 5:24 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! > Agreed. Unless someone remembers a specific justification for not having > visibility constraints on LinkActions, I would not be adverse to adding > them. The constraint could probably be added to LinkEndData and apply to all > LinkActions. Well, take "package" visibility as an example. If I remember right, this means that items with this visibility have only visibility to elements in the package where that item is defined. It sounds to me as if this implies keeping complex tables around identifying who can see what in which object. This is precisely the thing that I was trying to avoid when I objected to the notion of visibility information being retained at run time (apologies to Ed for using this term). Am I misreading this? Bran From: "Ed Seidewitz" To: "'Mellor, Stephen'" , Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 18:04:26 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5QAABOFtAAAFARAAABCFrgAACAP0A= > > Which is why I said: > > >OTOH, we could conflate visibitility in this context with > navigability. > > > More precisely, that part of the several elements of the > definition of > > > navigability that equate to the concept of visibility. Well, I did kind of ignore that, because I really don't know precisely what you mean by "conflate" and I really don't want to open up all the arguments about navigability again. I think that there is even less consensus on navigability than visibility in UML 2 right now, so I don't see how we gain much clarity on visibility by considering it in the context of navigability! Right now, navigability applies _only_ to ReadLinkAction. It does not apply to CreateLinkAction or DestroyLinkAction, nor does it apply the ReadStructuralFeatureAction or WriteStructuralFeature action. So I am not sure there is anything to conflate (_inflate_ maybe, but not conflate...). -- Ed From: "Ed Seidewitz" To: Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 18:08:21 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5QAABOFtAAAFARAAABNn/QAACLp9A= > Good example Ed, which clarified the question for me. > > It seems clear to me that what you describe as the current > meaning of the spec is desirable - it should be legal to make > a change that indirectly affects the value of B.y even though > it is private: since B.y does not need to be visible in order > for the update to happen. > To me it seems akin to the behavior attached to A calling a > public operation on B that has some logic updating y. Again y > is updated despite being private but most people would not > have an issue with this. Except, in your example, the operation updating B::y is defined in the context of B and, therefore, it should have access to the private properties of B. On the other hand, in my example, the CreateLinkAction is included as part of the method of an operation on class _A_. Should it be possible for an operation of class A to, in this way, modify the value of a private property of class B? Doesn't this violate encapsulation? -- Ed Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 18:23:16 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 4448 on ballot 8: please take note! Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5QAABOFtAAAFARAAABNn/Q From: "Pete Rivett" To: "Ed Seidewitz" , "Mellor, Stephen" , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j7NMJIhh010100 Good example Ed, which clarified the question for me. It seems clear to me that what you describe as the current meaning of the spec is desirable - it should be legal to make a change that indirectly affects the value of B.y even though it is private: since B.y does not need to be visible in order for the update to happen. To me it seems akin to the behavior attached to A calling a public operation on B that has some logic updating y. Again y is updated despite being private but most people would not have an issue with this. Pete 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 > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] > Sent: Tuesday, August 23, 2005 10:24 PM > To: 'Mellor, Stephen'; uml2-rtf@omg.org > Subject: RE: Issue 4448 on ballot 8: please take note! > > Steve -- > > > There is no need for visibility constraints on link/unlink: > > The association is right there in front you! > > Well, if "you" are the modeler, then everything is right > there in front of > you! If "you" are a class, however, then the whole point of visibility > annotations is to restrict what "you" can see in other classes. > > Remember, we are not discussing the visibility of the > association, but the > visibility of its ends, which can be owned by (and hence in > the namespace > of) the classes of those ends. It is thus possible (believe > it or not) to > have visibility to the associations, but not its ends! > > Suppose that association R has two association ends, x and y. > Suppose that > class A owns end x and class B owns end y and, further, > declares y to be > private. Suppose there is a behavior attached to class A that > includes a > create link zction for association R. Should this be legal, > even though it > will result in a change to the value of y, which is a > property declared to > be private to B? Right now it is. On the other hand, it would > not be legal > for a WriteStructuralFeatureAction in the context of class A > to write to the > private property y in class B. > > -- Ed > > > From: "Ed Seidewitz" To: Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 18:42:43 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5QAABOFtAAAFARAAABNn/QAACLp9AAAMBz0AAAbQuw > I know - I did say 'akin' not identical A still 'more > akin' example then: lets say that B::/p is a private property > but derived and its value depends on the (public) A::q. An > update to A::q will thus indirectly update the private B::/p > - but surely should be legal. But one would still expect the derivation of B::p to be specified in the context of class B. In effect, class B is declaring that, for its own uses, it will keep its own property y in sync with the publich property q of A. I don't think there is any problem with this. If, on the other hand, the derivation constraint for B::p was given as part of the definition of class A, then I think it would be very hard to understand the specification of B at all. The whole point of declaring a property to be private is that you don't have to look outside its class to understand how it is used and changed. Isn't this what encapsulation is? -- Ed Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 18:51:55 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 4448 on ballot 8: please take note! Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5QAABOFtAAAFARAAABNn/QAACLp9AAAMBz0A== From: "Pete Rivett" To: "Ed Seidewitz" , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j7NMm5hh010362 I know - I did say 'akin' not identical A still 'more akin' example then: lets say that B::/p is a private property but derived and its value depends on the (public) A::q. An update to A::q will thus indirectly update the private B::/p - but surely should be legal. Pete 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 > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] > Sent: Tuesday, August 23, 2005 11:08 PM > To: uml2-rtf@omg.org > Subject: RE: Issue 4448 on ballot 8: please take note! > > > > Good example Ed, which clarified the question for me. > > > > It seems clear to me that what you describe as the current > > meaning of the spec is desirable - it should be legal to make > > a change that indirectly affects the value of B.y even though > > it is private: since B.y does not need to be visible in order > > for the update to happen. > > To me it seems akin to the behavior attached to A calling a > > public operation on B that has some logic updating y. Again y > > is updated despite being private but most people would not > > have an issue with this. > > Except, in your example, the operation updating B::y is defined in the > context of B and, therefore, it should have access to the > private properties > of B. On the other hand, in my example, the CreateLinkAction > is included as > part of the method of an operation on class _A_. Should it be > possible for > an operation of class A to, in this way, modify the value of a private > property of class B? Doesn't this violate encapsulation? > > -- Ed > > > Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 19:49:25 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 4448 on ballot 8: please take note! Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5QAABOFtAAAFARAAABNn/QAACLp9AAAMBz0AAAbQuwAACT7NA= From: "Pete Rivett" To: "Ed Seidewitz" , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j7NNjQhh010823 > But one would still expect the derivation of B::p to be > specified in the > context of class B. In effect, class B is declaring that, for > its own uses, > it will keep its own property y in sync with the publich > property q of A. I > don't think there is any problem with this. Likewise, in the original example, the Association R is declaring that it will keep its end B::y in sync with A::x. Regardless of whether B::y is visible or not, that is part of the 'contract' of R: that's what it means to have an association. In general it should be possible to have an effect on properties that cannot be seen by the instigator of the action: I see no problem with this. If the createLinkAction is not legal, it would be impossible to set the (so-called) public property A::x except from behavior attached to B. Is that the intention? Taken further, this would then imply a constraint that in order for visibility to 'mean what it says' then the elements from which any updateable (isReadOnly=false) AssociationEnd is visible must include those from which the other end is visible. i.e. to ensure that wherever A::x can be updated then B::y is also visible. The example does not meet this constraint, and so to say A::x is 'public' is not meaningful. This can be determined statically. [This is an attempt at reductio ad absurdum in support of my originally-stated preference for the specification status quo] 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 > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] > Sent: Tuesday, August 23, 2005 11:43 PM > To: uml2-rtf@omg.org > Subject: RE: Issue 4448 on ballot 8: please take note! > > > I know - I did say 'akin' not identical A still 'more > > akin' example then: lets say that B::/p is a private property > > but derived and its value depends on the (public) A::q. An > > update to A::q will thus indirectly update the private B::/p > > - but surely should be legal. > > But one would still expect the derivation of B::p to be > specified in the > context of class B. In effect, class B is declaring that, for > its own uses, > it will keep its own property y in sync with the publich > property q of A. I > don't think there is any problem with this. > > If, on the other hand, the derivation constraint for B::p was > given as part > of the definition of class A, then I think it would be very hard to > understand the specification of B at all. The whole point of > declaring a > property to be private is that you don't have to look outside > its class to > understand how it is used and changed. Isn't this what > encapsulation is? > > -- Ed > > > From: "Ed Seidewitz" To: Subject: RE: Issue 4448 on ballot 8: please take note! Date: Tue, 23 Aug 2005 20:21:41 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5QAABOFtAAAFARAAABNn/QAACLp9AAAMBz0AAAbQuwAACT7NAAAqT4QA== Pete -- > Likewise, in the original example, the Association R is > declaring that it will keep its end B::y in sync with A::x. > Regardless of whether B::y is visible or not, that is part of > the 'contract' of R: that's what it means to have an association. > In general it should be possible to have an effect on > properties that cannot be seen by the instigator of the > action: I see no problem with this. Well, I am not sure what "in sync with" means, in the context of the association R. If R is not an association class, then a link is determined by its end values. You can't change the value at one end without effectively destroying the old end and creating a new one. That is why the issue here is whether the behavior of Create/DestroyLinkAction should be consistent with WriteStructuralFeatureAction. Otherwise, you can do with Create/DestroyLinkAction exactly what you are specifically prevented from doing in the case of WriteStructuralFeatureAction. Would you also argue for removing the visibility constraint on StructuralFeatureActions? In that case, what would visibility mean? > If the createLinkAction is not legal, it would be impossible > to set the > (so-called) public property A::x except from behavior > attached to B. Is that the intention? That's not true. Since A::x is publicly visible, it can be set using a WriteStructuralFeatureAction in the context of any class. This has the effect of destroying the old link and creating a new link. But the new link has the same value for B::y. So the action has not violated encapsulation. Admittedly, it would not be possible to do a CreateLinkAction from any class but B. But I would submit that this is consistent. If you wanted to be able to do a CreateLinkAction from outside B, you should make B::y publicly visible. Indeed, if you are going to use Create/DestroyLinkActions, it probably makes more sense to have the ends owned by the association itself, in any case. -- Ed Subject: RE: Issue 4448 on ballot 8: please take note! Date: Wed, 24 Aug 2005 02:22:14 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 4448 on ballot 8: please take note! Thread-Index: AcWoIsbxNGUbIWdiRCuv8C0VCEZsgwAAoL5QAABOFtAAAFARAAABNn/QAACLp9AAAMBz0AAAbQuwAACT7NAAAqT4QAAL0tGg From: "Pete Rivett" To: "Ed Seidewitz" , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j7O6INhh013273 > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] > Sent: Wednesday, August 24, 2005 1:22 AM > To: uml2-rtf@omg.org > Subject: RE: Issue 4448 on ballot 8: please take note! > > Pete -- > > > Likewise, in the original example, the Association R is > > declaring that it will keep its end B::y in sync with A::x. > > Regardless of whether B::y is visible or not, that is part of > > the 'contract' of R: that's what it means to have an association. > > In general it should be possible to have an effect on > > properties that cannot be seen by the instigator of the > > action: I see no problem with this. > > Well, I am not sure what "in sync with" means, in the context of the > association R. If R is not an association class, then a link > is determined > by its end values. You can't change the value at one end > without effectively > destroying the old end and creating a new one. That is why > the issue here is > whether the behavior of Create/DestroyLinkAction should be > consistent with > WriteStructuralFeatureAction. Otherwise, you can do with > Create/DestroyLinkAction exactly what you are specifically > prevented from > doing in the case of WriteStructuralFeatureAction. Fine by me: they are different actions (albeit with a similar effect) > Would you > also argue for > removing the visibility constraint on > StructuralFeatureActions? No. See above. > In that > case, what would visibility mean? > > > If the createLinkAction is not legal, it would be impossible > > to set the > > (so-called) public property A::x except from behavior > > attached to B. Is that the intention? > > That's not true. Since A::x is publicly visible, it can be set using a > WriteStructuralFeatureAction in the context of any class. This has the > effect of destroying the old link and creating a new link. > But the new link has the same value for B::y. Yes but potentially for a different instance of B. If A1::x = B1 then setting it (via WriteStructuralFeatureAction) to B2 will cause B1::y to no longer reference A1 and B2::y to be updated to now reference A1. > So the action has not violated encapsulation. > > Admittedly, it would not be possible to do a CreateLinkAction > from any class > but B. But I would submit that this is consistent. If you > wanted to be able > to do a CreateLinkAction from outside B, you should make B::y publicly > visible. This does not seem necessary nor desirable and can be avoided if we retain the 'current' version of the spec. The alternative seesm to force us into these somewhat non-obvious contortions. > Indeed, if you are going to use Create/DestroyLinkActions, it > probably makes more sense to have the ends owned by the > association itself, in any case. As above. BTW even if you wanted to do this, there is no notation for a navigable association end owned by the Association. Something we need to fix pretty quick. > > -- Ed > > > > Reply-To: From: "Conrad Bock" To: "Branislav Selic" , "Ed Seidewitz" Cc: Subject: RE: Issue 4448 on ballot 8: please take note! Date: Wed, 24 Aug 2005 16:11:03 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > The concern > that I have with what Conrad wants is that it requires a dynamic > manifestation. I didn't mean to say that, it's supposed to only be static constraints on the model, like a compiler mighht check for. Which part of the proposal implies dynamics? Conrad Reply-To: From: "Conrad Bock" To: "Pete Rivett" , "Ed Seidewitz" , Subject: RE: Issue 4448 on ballot 8: please take note! Date: Wed, 24 Aug 2005 16:16:34 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Pete, Ed, OK, have you guys figured out all the rules yet? If so, could you write them up with the design decisions? Thx, Conrad To: Cc: "Ed Seidewitz" , uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 24 Aug 2005 16:29:09 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/24/2005 16:29:10, Serialize complete at 08/24/2005 16:29:10 > > The concern > > that I have with what Conrad wants is that it requires a dynamic > > manifestation. > > I didn't mean to say that, it's supposed to only be static constraints > on the model, like a compiler mighht check for. Which part of the > proposal implies dynamics? I guess I misunderstood your position. I had presumed it based on your objection to my explanation that visibility was a "compile time" thing (I should have said "static" I guess). Apologies for any confusion. Bran To: "Ed Seidewitz" Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 24 Aug 2005 16:51:16 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/24/2005 16:51:17, Serialize complete at 08/24/2005 16:51:17 "Ed Seidewitz" wrote on 08/23/2005 08:21:41 PM: > Well, I am not sure what "in sync with" means, in the context of the > association R. If R is not an association class, then a link is determined > by its end values. You can't change the value at one end without effectively > destroying the old end and creating a new one. Not to deflect the discussion too much, but links belonging to associations that are not association classes can also have identities that are distinct from their end values (in the case of "non-unique" ends). (One could argue that this automatically makes it an association class, but this is not how the spec deals with it; for example, MOF -- which is based on the Infrastructure -- has no concept of an association class, but it does have "non-unique" associations.) > That is why the issue here is > whether the behavior of Create/DestroyLinkAction should be consistent with > WriteStructuralFeatureAction. ...for the case of "unique" association ends. > Otherwise, you can do with > Create/DestroyLinkAction exactly what you are specifically prevented from > doing in the case of WriteStructuralFeatureAction. (I wonder what these actions will do for cases where one end of an association is defined as "unique" and the other is "non-unique"? Will a DestroyLinkAction executed from the object with the "unique" view of the association destroy all links seen by the "non-unique" end in cases where there is more than one or just one? This stuff is getting very complicated.) Bran Subject: RE: Issue 4448 on ballot 8: please take note! Date: Wed, 24 Aug 2005 14:34:22 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 4448 on ballot 8: please take note! Thread-Index: AcWo7aEnzYFCqWRXT3eBBKO6E4fCqwABBjsw From: "Pete Rivett" To: "Branislav Selic" , "Ed Seidewitz" Cc: (I wonder what these actions will do for cases where one end of an association is defined as "unique" and the other is "non-unique"? Will a DestroyLinkAction executed from the object with the "unique" view of the association destroy all links seen by the "non-unique" end in cases where there is more than one or just one? This stuff is getting very complicated.) Issue 5977 asserts (and I agree) that there can be no such an Association (with one end unique and the other not). Pete -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, August 24, 2005 9:51 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! "Ed Seidewitz" wrote on 08/23/2005 08:21:41 PM: > Well, I am not sure what "in sync with" means, in the context of the > association R. If R is not an association class, then a link is determined > by its end values. You can't change the value at one end without effectively > destroying the old end and creating a new one. Not to deflect the discussion too much, but links belonging to associations that are not association classes can also have identities that are distinct from their end values (in the case of "non-unique" ends). (One could argue that this automatically makes it an association class, but this is not how the spec deals with it; for example, MOF -- which is based on the Infrastructure -- has no concept of an association class, but it does have "non-unique" associations.) > That is why the issue here is > whether the behavior of Create/DestroyLinkAction should be consistent with > WriteStructuralFeatureAction. ...for the case of "unique" association ends. > Otherwise, you can do with > Create/DestroyLinkAction exactly what you are specifically prevented from > doing in the case of WriteStructuralFeatureAction. (I wonder what these actions will do for cases where one end of an association is defined as "unique" and the other is "non-unique"? Will a DestroyLinkAction executed from the object with the "unique" view of the association destroy all links seen by the "non-unique" end in cases where there is more than one or just one? This stuff is getting very complicated.) Bran To: "Pete Rivett" Cc: "Ed Seidewitz" , uml2-rtf@omg.org Subject: RE: Issue 4448 on ballot 8: please take note! X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 24 Aug 2005 17:51:14 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/24/2005 17:51:15, Serialize complete at 08/24/2005 17:51:15 > (I wonder what these actions will do for cases where one end of an > association is defined as "unique" and the other is "non-unique"? > Will a DestroyLinkAction executed from the object with the "unique" > view of the association destroy all links seen by the "non-unique" > end in cases where there is more than one or just one? This stuff is > getting very complicated.) > Issue 5977 asserts (and I agree) that there can be no such an > Association (with one end unique and the other not). I was expecting someone to bring that up, but I don't see why there cannot be such an association. It is certainly feasible. Actually, this is a topic that I think is quite important -- even more important than the visibility issue, since it delves into the whole meaning of what associations and links represent. Bran Reply-To: From: "Conrad Bock" To: "Branislav Selic" , "Pete Rivett" Cc: "Ed Seidewitz" , Subject: RE: Issue 4448 on ballot 8: please take note!, unique/nonunique ends Date: Thu, 25 Aug 2005 16:00:38 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) > > [Pete] Issue 5977 asserts (and I agree) that there can be no such an > > Association (with one end unique and the other not). > > [Bran]I was expecting someone to bring that up, but I don't see why > there cannot be such an association. It is certainly feasible. I agree with Bran, but lok for gotchas. Eg, if an object instance with a non-unique property/end that has another object as a value twice, and the property on the other end is unique (only one object value "pointing back" would appear), then removing the value on the unique end presumably would remove both on the non-unique end. Conrad Reply-To: From: "Conrad Bock" To: "uml2rtf" Subject: RE: Issue 4448, proposal Date: Sat, 27 Aug 2005 12:14:50 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, et al, Here a proposal for 4448, based on the email discussion. If it looks OK, can update it for any changes to infrastructure. Conrad Reply-To: From: "Conrad Bock" To: "Branislav Selic" , , "Eran Gery" , Cc: Subject: RE: Draft ballot 10 Date: Tue, 13 Sep 2005 10:37:08 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Thanks. Comments on comments, and updates attached. Conrad > 4448: needs to specify Infrastructure fixes See attached. Since infra has no behaviors so can't refer to actions accessing operations, etc, I generalized the wording a bit to omit reference to behaviors and actions. This might be just as well for super also, since the text is in the Clases chapter. > 6444: I agree that some of the things are unclear in this issue > text, but I think that the clarification sought under item (b) > is fairly clear and probably should be answered. There are so many definitions of "continuous" that it's hard to (summarize We identified a half-dozen relevant meanings during SysML development, which are explained in separate paper to appear later). Super FTF issue 6902 addressed one aspect briefly in section 6.3. I added reference to it in the attached update. > I think, though, that the clarifying text should be included in > section 6.3 and not in the activities (NB: in that case, a > corresponding Infrastructure fix would have to be included as well). Not sure if there was an infrastructure issue corresponding to Super FTF issue 6902 was filed, but I didn't see any of the 6902 resolution in ptc/04-10-14 (there isn't even a runtime semantics section in the infra). If the 6902 resolution should have been propagated to infrastructure, perhaps it can be taken as an editorial fix on the FTF product. > 8271: I think it would be helpful to add an explanation that the > submitter is making an incorrect assumption that a convention > exists such that all elements in a metamodel diagram are > necessarily connected. The diagrams represent groupings based on > subject matter, which does not always imply that the elements > are directly connected (e.g., the connections may occur at more > general levels). OK, see update. aawg-ballot-101.doc a link?