Issue 6464: UML 2 Issue: isUnique (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: PROBLEM STATEMENT "When one or more ends of the association have isUnique=false, it is possible to have several links associating the same set of instances." (Superstructure, p. 81) As Pierre-Alain Muller demonstrated in an informal conversation with Bran Selic during a lunch in San Francisco in the last UML Conference (I also was taking part in that conversation), isUnique must have the same value for all ends in an association. This has implications, for example, for the property strings that can be placed near the association ends ({ordered}, {bag}, {seq}). According to the table in Superstructure, p. 92, if one end is a Set or an OrderedSet, then the opposite end must be a Set or an OrderedSet, too; and if one end is a Bag or a Sequence, then the opposite end must be a Bag or a Sequence, too. PROPOSED SOLUTION Explain this in the Spec. Resolution: Revised Text: Actions taken: November 7, 2003: received issue February 18, 2005: moved from infrastructure Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== ubject: Fw: UML 2 Issue: isUnique X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 7 Nov 2003 08:31:01 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 11/07/2003 08:31:08, Serialize complete at 11/07/2003 08:31:08 Issue raised by Gonzalo Genova. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com ----- Forwarded by Branislav Selic/Ottawa/IBM on 11/07/2003 07:49 AM ----- Gonzalo Genova 11/06/2003 01:34 PM To: "'issues@omg.org'" , Branislav Selic/Ottawa/IBM@IBMCA, "'pa.muller@uha.fr'" cc: "Juan Llorens (inf)" , "J.Miguel Fuentes Torres" Subject: UML 2 Issue: isUnique This issue refers to UML 2.0 Infrastructure Specification (ptc/03-09-15) and UML 2.0 Superstructure Specification (ptc/03-08-02). PROBLEM STATEMENT "When one or more ends of the association have isUnique=false, it is possible to have several links associating the same set of instances." (Superstructure, p. 81) As Pierre-Alain Muller demonstrated in an informal conversation with Bran Selic during a lunch in San Francisco in the last UML Conference (I also was taking part in that conversation), isUnique must have the same value for all ends in an association. This has implications, for example, for the property strings that can be placed near the association ends ({ordered}, {bag}, {seq}). According to the table in Superstructure, p. 92, if one end is a Set or an OrderedSet, then the opposite end must be a Set or an OrderedSet, too; and if one end is a Bag or a Sequence, then the opposite end must be a Bag or a Sequence, too. PROPOSED SOLUTION Explain this in the Spec. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=lpVDABfu1IGbqUcXg5pt/Ph60ESmxCAwPKfmLpdvfaA=; b=v6V2sqQd+4wQFE7cEMb5IduptsUmjSOc7MF1ST4RW1RAhgwutKCiCJGq1DPj8nfW6O gAMEwcUvCyQJMfJflbAbFlS5TijrrWUhpNhl7FhxPlH34ExPgcWkTQaFHqkQqXGmMKP+ P6R7iXOPNQe+iaTw9zRn2jYy9MLH3l4k5sEgXTtN/5irMA26aRN0Vx45pPIszkmBAF3D IiE5/WRI++0xp8E4dXKPTR8wVu1p/0omFkpp9PXEqRAuxG8QeHlYJLSYCevo3Y/0K+aH 4c+pxJ2LNEFLR2br5tey5a91c/SOj93NDE/kPr6xYhwFP41fvmDueb12HEBC8hVjw9dq jz3Q== X-Received: by 10.52.95.39 with SMTP id dh7mr1704004vdb.26.1367947414766; Tue, 07 May 2013 10:23:34 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Tue, 7 May 2013 13:22:54 -0400 X-Google-Sender-Auth: OqHt-18XXvvl_Oh3oSRwTVEw5SE Subject: Resolution 6464 - doubts To: "uml25-ftf@omg.org" X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Although I had agreed with the submitter of the issue at the time, I've had doubts about whether or not "isUnique" necessarily has to apply to both ends of an association. The doubt is prompted by the so-called "Milicev interpretation" of links. Namely, in his excellent book on UML, Miliceve provides one possible interpretation of links in which a bidirectional link can be interpreted as representing two mappings: one from an instance of class A to one or more instances of class B (depending on multiplicity), representing one end of the association, while the other end is represented by a mapping going in the opposite direction, from class B to class A. In that interpretation, it is possible for the "isUnique" property to be different for the two ends. If you read the text of the spec (but excluding fUML), there is, as far as I can tell, nothing that prevents this interpretation, which, in my view is not an unreasonable one -- even though I personally never thought of a link that way when I first encountered the concept. So, I would prefer this issue to be discussed further before we decide on the resolution, especially since I know of at least one tool that has adopted this interpretation. Bran X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=XMMJF2RE c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=GLk8ytPYtoUA:10 a=pGLkceISAAAA:8 a=oCcaPWc0AAAA:8 a=UEsl2iB30DY3RVxiJ4QA:9 a=Ov5kao9bMN50j8-C:21 a=wPNLvfGTeEIA:10 a=_W_S_7VecoQA:10 Date: Tue, 07 May 2013 18:37:25 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "uml25-ftf@omg.org" Subject: Re: Resolution 6464 - doubts X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Hi Ecore (and I think EMOF too) have independent isUnique. Regards Ed Willink On 07/05/2013 18:22, Bran Selic wrote: Although I had agreed with the submitter of the issue at the time, I've had doubts about whether or not "isUnique" necessarily has to apply to both ends of an association. The doubt is prompted by the so-called "Milicev interpretation" of links. Namely, in his excellent book on UML, Miliceve provides one possible interpretation of links in which a bidirectional link can be interpreted as representing two mappings: one from an instance of class A to one or more instances of class B (depending on multiplicity), representing one end of the association, while the other end is represented by a mapping going in the opposite direction, from class B to class A. In that interpretation, it is possible for the "isUnique" property to be different for the two ends. If you read the text of the spec (but excluding fUML), there is, as far as I can tell, nothing that prevents this interpretation, which, in my view is not an unreasonable one -- even though I personally never thought of a link that way when I first encountered the concept. So, I would prefer this issue to be discussed further before we decide on the resolution, especially since I know of at least one tool that has adopted this interpretation. Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6306 - Release Date: 05/07/13 From: Steve Cook To: Bran Selic , "uml25-ftf@omg.org" Subject: RE: Resolution 6464 - doubts Thread-Topic: Resolution 6464 - doubts Thread-Index: AQHOS0eCbIyk0bODQUqereLJw60VqZj6FCLA Date: Tue, 7 May 2013 19:29:14 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(189002)(199002)(46102001)(74366001)(56776001)(65816001)(79102001)(81542001)(76482001)(54316002)(20776003)(4396001)(63696002)(80022001)(50986001)(47976001)(51856001)(77982001)(49866001)(47736001)(74876001)(15202345002)(53806001)(81342001)(74662001)(74502001)(47446002)(16236675002)(69226001)(54356001)(74706001)(31966008)(71186001)(59766001)(55846006)(16406001)(56816002)(6806003)(512954002)(33656001);DIR:OUT;SFP:;SCL:1;SRVR:BN1AFFO11HUB012;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0839D067E7 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. If we were to adopt Milicev.s semantics, we.d need to clearly distinguish between the collection of instances represented by the value of the property, vs the underlying links. It would also affect the definition of multiplicity. Currently, multiplicity constrains the number of links, not the number of objects in the collection; and with Milicev.s interpretation there could be (say) 2 links and one object. Adopting Milicev.s semantics would be a major and disruptive change. However, if we were to permit Milicev to conform to the abstract syntax but not the semantics, then we.d need to not have the constraint. In which case we.d need some words to admit this possibility. I am open to this as a way forward. Maybe we can discuss next week. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 07 May 2013 18:23 To: uml25-ftf@omg.org Subject: Resolution 6464 - doubts Although I had agreed with the submitter of the issue at the time, I've had doubts about whether or not "isUnique" necessarily has to apply to both ends of an association. The doubt is prompted by the so-called "Milicev interpretation" of links. Namely, in his excellent book on UML, Miliceve provides one possible interpretation of links in which a bidirectional link can be interpreted as representing two mappings: one from an instance of class A to one or more instances of class B (depending on multiplicity), representing one end of the association, while the other end is represented by a mapping going in the opposite direction, from class B to class A. In that interpretation, it is possible for the "isUnique" property to be different for the two ends. If you read the text of the spec (but excluding fUML), there is, as far as I can tell, nothing that prevents this interpretation, which, in my view is not an unreasonable one -- even though I personally never thought of a link that way when I first encountered the concept. So, I would prefer this issue to be discussed further before we decide on the resolution, especially since I know of at least one tool that has adopted this interpretation. Bran DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ZgE+Bb0mDp6hOCxANkVMtZ9GJ478a8gQpWaRAR+HMmA=; b=UoDNwzx3fF6UZvY6RfSjTGo7sRmMX8cJNDmI9gPEPws5xtxjJenfofs6wb6y0RRfkU oe+XBvtYzJjTdHQ+Or/hMjRMZS6Gk4HOTO6cpMGLCTP7QLda9JC2BkJROks180faMhWU 0b5sBQDnj7U4GZpxvRH6Rz6ZXOfeMhrn0u0W+v+xPgOFHbeuUC6BsWDNM0JqR+oE6r5F UWsiWHEH7OVKBqKqbFbH/6doK2xL9pMlsQPUmaoIBWpCpvcoHLEefxNKDU6lKLqrO4GT uDRX2wYT//zRu/qIfqYyX/okNelBYYLE4LKOhq7cXWHEdlvxEY9TidTVGwXtcpcZoa4A 152g== X-Received: by 10.220.100.138 with SMTP id y10mr3658450vcn.51.1367998736273; Wed, 08 May 2013 00:38:56 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 8 May 2013 03:38:15 -0400 X-Google-Sender-Auth: KaZsK6cdro88r5oa9wh_UIjyVvI Subject: Re: Resolution 6464 - doubts To: Steve Cook Cc: "uml25-ftf@omg.org" X-Virus-Scanned: amavisd-new at omg.org On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran From: Steve Cook To: Bran Selic CC: "uml25-ftf@omg.org" Subject: RE: Resolution 6464 - doubts Thread-Topic: Resolution 6464 - doubts Thread-Index: AQHOS0eCbIyk0bODQUqereLJw60VqZj6FCLAgADTToCAAAlMYA== Date: Wed, 8 May 2013 08:25:23 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(189002)(199002)(377454002)(24454002)(20776003)(4396001)(47736001)(16406001)(6806003)(56816002)(56776001)(50986001)(47976001)(33656001)(54316002)(8558605002)(77982001)(79102001)(49866001)(55846006)(74366001)(63696002)(15202345002)(16236675002)(80022001)(74876001)(69226001)(74706001)(44976003)(53806001)(46102001)(47446002)(31966008)(71186001)(512954002)(74502001)(81342001)(51856001)(74662001)(81542001)(59766001)(54356001)(65816001)(76482001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB025;H:TK5EX14MLTC102.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 084080FC15 X-Virus-Scanned: amavisd-new at omg.org Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran From: Steve Cook To: Bran Selic , "uml25-ftf@omg.org" Subject: RE: Resolution 6464 - doubts Thread-Topic: Resolution 6464 - doubts Thread-Index: AQHOS0eCbIyk0bODQUqereLJw60VqZj6FCLAgADTToCAAAlMYIAAEiNQ Date: Wed, 8 May 2013 09:30:37 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(24454002)(189002)(199002)(377454002)(79102001)(74502001)(8558605002)(54356001)(51856001)(53806001)(55846006)(65816001)(33656001)(56776001)(44976003)(47446002)(74662001)(31966008)(6806003)(80022001)(76482001)(20776003)(54316002)(81542001)(63696002)(77982001)(16236675002)(512954002)(46102001)(15202345002)(74876001)(69226001)(47736001)(50986001)(4396001)(47976001)(49866001)(81342001)(74706001)(16406001)(59766001)(56816002)(71186001)(74366001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB024;H:TK5EX14MLTC104.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 084080FC15 X-Virus-Scanned: amavisd-new at omg.org Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=XMMJF2RE c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=GLk8ytPYtoUA:10 a=yMhMjlubAAAA:8 a=KHpXyVWLAAAA:8 a=HNVTiTzpAAAA:8 a=pGLkceISAAAA:8 a=oCcaPWc0AAAA:8 a=VXWOgDI2fhq5jWA4v30A:9 a=rPd522YhiFvWuy4J:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=6UIaq3Bcl8oA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=-AOE9ft50oIA:10 a=WP4_USCxRkkA:10 a=MSl-tDqOz04A:10 Date: Wed, 08 May 2013 21:00:55 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "uml25-ftf@omg.org" Subject: Re: Resolution 6464 - doubts X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 From: Steve Cook To: Ed Willink , "uml25-ftf@omg.org" Subject: RE: AW: Resolution 6464 - doubts Thread-Topic: AW: Resolution 6464 - doubts Thread-Index: AQHOS0eCbIyk0bODQUqereLJw60VqZj6FCLAgADTToCAAAlMYIAAEiNQgAC0EYCAACA6AIAAg1OAgAA20zA= Date: Thu, 9 May 2013 09:24:58 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(52034003)(24454002)(377454002)(479174002)(199002)(189002)(15974865001)(76482001)(55846006)(74366001)(54356001)(53806001)(80022001)(74706001)(47736001)(47976001)(81542001)(33656001)(81342001)(71186001)(49866001)(44976003)(20776003)(512954002)(16601075002)(69226001)(47446002)(74502001)(31966008)(16236675002)(15202345002)(8558605002)(79102001)(50986001)(74876001)(4396001)(74662001)(56816002)(16406001)(59766001)(46102001)(6806003)(51856001)(77982001)(65816001)(56776001)(54316002)(63696002);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB015;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08417837C5 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== Let.s just be clear that if we don.t adopt Milicev.s idea, the implications are that we need to constrain UML models so that if any end of an association is nonUnique, then all other ends of that association must be nonunique and have multiplicity upper bound > 1. This renders Milicev.s work .non-compliant., both semantically and syntactically, and more than likely invalidates many existing models. Ed, as regards this so-called .obvious. constraint about which you are arguing, it makes no sense to me. The ->size() operation would work on the collection resulting from whichever semantics are in operation. As Axel says, the constraint (were it to be formulated correctly) is satisfied either way. I do not agree with your argument, or that Milicev.s interpretation is anything like .dangerously cute.. Perhaps there is a way through here. Most models (e.g. the UML metamodel) actually mark all ends as unique (the default). The issue only arises when ends are marked as nonunique. If we introduce Milicev.s semantics as a way of explaining what it means to have a non-unique end amongst unique ends, then we don.t need to invalidate any models, we can have a clear and unambiguous semantics, and Milicev.s work can comply with it. Thanks -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 09 May 2013 06:46 To: uml25-ftf@omg.org Subject: Re: AW: Resolution 6464 - doubts Hi Axel Oops. Yes element is a collection so element = self is functionally stupid but not semantically illegal. Your element->includes(self) has a projection and so gives the intentional semantics I meant context Object inv ConsistentRestrictiveContainment: self.parent->size() = Container.allInstances().element->select(e | e = self)->size() [which is short for Container.allInstances()->collect(c | c.element->select(e | e = self))->size()] the difference is that the intentional semantics has the projection context Object inv ConsistentIntentionalContainment: self.parent->size() = Container.allInstances().element->asSet()->select(e | e = self)->size() Regards Ed Willink On 08/05/2013 22:56, Axel Scheithauer wrote: Hi, I might be wrong, but shouldn.t the .obvious. constraint look like this: context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element->includes(self))->size() Since element is a collection, element=self is not possible. (By the way, in the original figure, .parent. is called .container.) I think this constraint is fulfilled, even with the .intentional. interpretation. Regards Axel Von: Ed Willink [mailto:ed@willink.me.uk] Gesendet: Mittwoch, 8. Mai 2013 22:01 An: uml25-ftf@omg.org Betreff: Re: Resolution 6464 - doubts Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com[mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6308 - Release Date: 05/08/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Wq0Sb7vv c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=VVvQjBrEMcMA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=5LlPfTAAGf4A:10 a=yMhMjlubAAAA:8 a=KHpXyVWLAAAA:8 a=HNVTiTzpAAAA:8 a=pGLkceISAAAA:8 a=oCcaPWc0AAAA:8 a=DEfF15jzu-UE8fXiHTUA:9 a=AiEra0-Rpm9r0Cr_:21 a=d5_8c1xyvRk4x7zo:21 a=o5DC1hS0pPhCo-fX:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=6UIaq3Bcl8oA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=WP4_USCxRkkA:10 a=-AOE9ft50oIA:10 a=MSl-tDqOz04A:10 Date: Thu, 09 May 2013 12:52:50 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "uml25-ftf@omg.org" Subject: Re: AW: Resolution 6464 - doubts X-Virus-Scanned: amavisd-new at omg.org Hi Steve Being "dangeously cute" is much less offensive that being broken, so maybe it's necessary. But if the UML specification currently has an ambiguity allowing either interpretation A or B, where interpretation A is widely assumed, is it correct to resolve the ambiguity by taking interpretation B? Whichever unambiguous interpretation is adopted will cause a compatibility problem for someone. If hybrid unique/nonunique associations are respecified according to the restrictive interpretation, old models accidentally using hybrids become explicitly invalid. Old models using intentional semantics become explicitly invalid. If hybrid unique/nonunique associations are respecified according to the intentional interpretation, old models accidentally using hybrids remain semantically valid but may start to behave differently as tooling evolves. Old models using intentional semantics become implicitly valid. [The intentional semantics is presumably not often required. It can easily be expressed using an asSet() somewhere.] I much prefer to to explicitly diagnose old models as broken than silently change their semantics. It is an inevitable consequence of tool evolution that checking steadily improves and so hidden user mistakes are exposed by new tooling. With the OCL in UML 2.5 so much improved and extended, users must expect latent bugs to be exposed. Tool vendors may need to offer a capability to configure warning suppression. ---- My 'obvious' constraint may be a chicken and egg example. Approach containment from two directions: The number of usages of a parent by self: self.parent->size() is equal to The number of usages of self as a child: Container.allInstances().element->select(e | e = self)->size() While writing the above, my first choice of English phrasing was "equal to the number of Containers for which self is a child" which gives the intentional semantics. ======= I'm uncomfortable with, but not violently opposed to the intentional semantics. Regards Ed Willink On 09/05/2013 10:24, Steve Cook wrote: Let.s just be clear that if we don.t adopt Milicev.s idea, the implications are that we need to constrain UML models so that if any end of an association is nonUnique, then all other ends of that association must be nonunique and have multiplicity upper bound > 1. This renders Milicev.s work .non-compliant., both semantically and syntactically, and more than likely invalidates many existing models. Ed, as regards this so-called .obvious. constraint about which you are arguing, it makes no sense to me. The ->size() operation would work on the collection resulting from whichever semantics are in operation. As Axel says, the constraint (were it to be formulated correctly) is satisfied either way. I do not agree with your argument, or that Milicev.s interpretation is anything like .dangerously cute.. Perhaps there is a way through here. Most models (e.g. the UML metamodel) actually mark all ends as unique (the default). The issue only arises when ends are marked as nonunique. If we introduce Milicev.s semantics as a way of explaining what it means to have a non-unique end amongst unique ends, then we don.t need to invalidate any models, we can have a clear and unambiguous semantics, and Milicev.s work can comply with it. Thanks -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 09 May 2013 06:46 To: uml25-ftf@omg.org Subject: Re: AW: Resolution 6464 - doubts Hi Axel Oops. Yes element is a collection so element = self is functionally stupid but not semantically illegal. Your element->includes(self) has a projection and so gives the intentional semantics I meant context Object inv ConsistentRestrictiveContainment: self.parent->size() = Container.allInstances().element->select(e | e = self)->size() [which is short for Container.allInstances()->collect(c | c.element->select(e | e = self))->size()] the difference is that the intentional semantics has the projection context Object inv ConsistentIntentionalContainment: self.parent->size() = Container.allInstances().element->asSet()->select(e | e = self)->size() Regards Ed Willink On 08/05/2013 22:56, Axel Scheithauer wrote: Hi, I might be wrong, but shouldn.t the .obvious. constraint look like this: context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element->includes(self))->size() Since element is a collection, element=self is not possible. (By the way, in the original figure, .parent. is called .container.) I think this constraint is fulfilled, even with the .intentional. interpretation. Regards Axel Von: Ed Willink [mailto:ed@willink.me.uk] Gesendet: Mittwoch, 8. Mai 2013 22:01 An: uml25-ftf@omg.org Betreff: Re: Resolution 6464 - doubts Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com[mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6308 - Release Date: 05/08/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6309 - Release Date: 05/08/13 From: Axel Scheithauer To: Ed Willink , "uml25-ftf@omg.org" Subject: AW: Resolution 6464 - doubts Thread-Topic: Resolution 6464 - doubts Thread-Index: AQHOS0h+avoFLV2O00qOwGMzmF+e8Jj5+jgAgADLr4CAAA0sgIAAEjmAgACwG4CAADpXAA== Date: Wed, 8 May 2013 21:56:16 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.171.161.1] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org Hi, I might be wrong, but shouldn.t the .obvious. constraint look like this: context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element->includes(self))->size() Since element is a collection, element=self is not possible. (By the way, in the original figure, .parent. is called .container.) I think this constraint is fulfilled, even with the .intentional. interpretation. Regards Axel Von: Ed Willink [mailto:ed@willink.me.uk] Gesendet: Mittwoch, 8. Mai 2013 22:01 An: uml25-ftf@omg.org Betreff: Re: Resolution 6464 - doubts Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Wq0Sb7vv c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=VVvQjBrEMcMA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=5LlPfTAAGf4A:10 a=KHpXyVWLAAAA:8 a=yMhMjlubAAAA:8 a=HNVTiTzpAAAA:8 a=pGLkceISAAAA:8 a=oCcaPWc0AAAA:8 a=i_jXT76nryqf5mvQCsgA:9 a=nJFTJeLyy2uuR1N1:21 a=NNGNBGQ7TdFFgBqZ:21 a=ixvU7ZB8YobU22li:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=WP4_USCxRkkA:10 a=-AOE9ft50oIA:10 a=MSl-tDqOz04A:10 Date: Thu, 09 May 2013 06:46:17 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "uml25-ftf@omg.org" Subject: Re: AW: Resolution 6464 - doubts X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== Hi Axel Oops. Yes element is a collection so element = self is functionally stupid but not semantically illegal. Your element->includes(self) has a projection and so gives the intentional semantics I meant context Object inv ConsistentRestrictiveContainment: self.parent->size() = Container.allInstances().element->select(e | e = self)->size() [which is short for Container.allInstances()->collect(c | c.element->select(e | e = self))->size()] the difference is that the intentional semantics has the projection context Object inv ConsistentIntentionalContainment: self.parent->size() = Container.allInstances().element->asSet()->select(e | e = self)->size() Regards Ed Willink On 08/05/2013 22:56, Axel Scheithauer wrote: Hi, I might be wrong, but shouldn.t the .obvious. constraint look like this: context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element->includes(self))->size() Since element is a collection, element=self is not possible. (By the way, in the original figure, .parent. is called .container.) I think this constraint is fulfilled, even with the .intentional. interpretation. Regards Axel Von: Ed Willink [mailto:ed@willink.me.uk] Gesendet: Mittwoch, 8. Mai 2013 22:01 An: uml25-ftf@omg.org Betreff: Re: Resolution 6464 - doubts Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com[mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6308 - Release Date: 05/08/13 From: Steve Cook To: Ed Willink , "uml25-ftf@omg.org" Subject: RE: AW: Resolution 6464 - doubts Thread-Topic: AW: Resolution 6464 - doubts Thread-Index: AQHOS0eCbIyk0bODQUqereLJw60VqZj6FCLAgADTToCAAAlMYIAAEiNQgAC0EYCAACA6AIAAg1OAgAA20zCAAC+WAIAACHXQ Date: Thu, 9 May 2013 13:13:09 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(52034003)(51444003)(199002)(189002)(24454002)(479174002)(377454002)(47736001)(71186001)(16601075002)(77982001)(49866001)(15202345002)(74366001)(512954002)(74706001)(47976001)(50986001)(81342001)(16236675002)(81542001)(33656001)(46102001)(6806003)(74876001)(80022001)(4396001)(54356001)(53806001)(44976003)(16406001)(65816001)(76482001)(56816002)(47446002)(56776001)(55846006)(74502001)(54316002)(8558605002)(79102001)(31966008)(74662001)(63696002)(20776003)(69226001)(59766001)(51856001)(15974865001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB031;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08417837C5 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== Ed Please see my interspersed comments. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 09 May 2013 12:53 To: uml25-ftf@omg.org Subject: Re: AW: Resolution 6464 - doubts Hi Steve Being "dangeously cute" is much less offensive that being broken, so maybe it's necessary. But if the UML specification currently has an ambiguity allowing either interpretation A or B, where interpretation A is widely assumed, It is extremely unlikely that interpretation A is widely assumed, especially by anybody who happened to create a hybrid association. If they were assuming interpretation A, they were intentionally creating an invalid model. It is much more likely that users assumed that hybrid associations had a valid semantics, since they were never warned of the opposite. is it correct to resolve the ambiguity by taking interpretation B? Whichever unambiguous interpretation is adopted will cause a compatibility problem for someone. If hybrid unique/nonunique associations are respecified according to the restrictive interpretation, old models accidentally using hybrids become explicitly invalid. They were always invalid. Old models using intentional semantics become explicitly invalid. Indeed. This is bad. If hybrid unique/nonunique associations are respecified according to the intentional interpretation, old models accidentally using hybrids remain semantically valid but may start to behave differently as tooling evolves. The old models were never valid, so could not .remain semantically valid.. There never was a valid behaviour that they could have had. Old models using intentional semantics become implicitly valid. No, they become explicitly valid. The spec will tell them what the models mean. This is good. [The intentional semantics is presumably not often required. It is only ever required for a hybrid association. It can easily be expressed using an asSet() somewhere.] Not so. The particular case where the intentional semantics adds value that asSet() cannot offer is a nonunique composition. In that case, the restrictive semantics would require a multiplicity of more than 1 at the container end, which prohibits the use of nonunique composition altogether. I think that would be a surprise to many users of UML. I much prefer to to explicitly diagnose old models as broken than silently change their semantics. It is an inevitable consequence of tool evolution that checking steadily improves and so hidden user mistakes are exposed by new tooling. With the OCL in UML 2.5 so much improved and extended, users must expect latent bugs to be exposed. Tool vendors may need to offer a capability to configure warning suppression. Nobody is .silently changing any semantics.. The only change would be that models that were previously silently invalid become valid. Presumably the creators of those models had something in mind, however vaguely, when they created a hybrid association. That thing they had in mind is likely to be the intentional semantics (*). I am unaware of any competing valid semantics for hybrid associations. ---- My 'obvious' constraint may be a chicken and egg example. Approach containment from two directions: The number of usages of a parent by self: self.parent->size() is equal to The number of usages of self as a child: Container.allInstances().element->select(e | e = self)->size() While writing the above, my first choice of English phrasing was "equal to the number of Containers for which self is a child" which gives the intentional semantics. Indeed. Which is further justification for (*) above. Of course if you have different semantics then you can find some different equations. But there is nothing .obvious. about this formulation with .usages.. It is just restating the question. ======= I'm uncomfortable with, but not violently opposed to the intentional semantics. Regards Ed Willink On 09/05/2013 10:24, Steve Cook wrote: Let.s just be clear that if we don.t adopt Milicev.s idea, the implications are that we need to constrain UML models so that if any end of an association is nonUnique, then all other ends of that association must be nonunique and have multiplicity upper bound > 1. This renders Milicev.s work .non-compliant., both semantically and syntactically, and more than likely invalidates many existing models. Ed, as regards this so-called .obvious. constraint about which you are arguing, it makes no sense to me. The ->size() operation would work on the collection resulting from whichever semantics are in operation. As Axel says, the constraint (were it to be formulated correctly) is satisfied either way. I do not agree with your argument, or that Milicev.s interpretation is anything like .dangerously cute.. Perhaps there is a way through here. Most models (e.g. the UML metamodel) actually mark all ends as unique (the default). The issue only arises when ends are marked as nonunique. If we introduce Milicev.s semantics as a way of explaining what it means to have a non-unique end amongst unique ends, then we don.t need to invalidate any models, we can have a clear and unambiguous semantics, and Milicev.s work can comply with it. Thanks -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 09 May 2013 06:46 To: uml25-ftf@omg.org Subject: Re: AW: Resolution 6464 - doubts Hi Axel Oops. Yes element is a collection so element = self is functionally stupid but not semantically illegal. Your element->includes(self) has a projection and so gives the intentional semantics I meant context Object inv ConsistentRestrictiveContainment: self.parent->size() = Container.allInstances().element->select(e | e = self)->size() [which is short for Container.allInstances()->collect(c | c.element->select(e | e = self))->size()] the difference is that the intentional semantics has the projection context Object inv ConsistentIntentionalContainment: self.parent->size() = Container.allInstances().element->asSet()->select(e | e = self)->size() Regards Ed Willink On 08/05/2013 22:56, Axel Scheithauer wrote: Hi, I might be wrong, but shouldn.t the .obvious. constraint look like this: context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element->includes(self))->size() Since element is a collection, element=self is not possible. (By the way, in the original figure, .parent. is called .container.) I think this constraint is fulfilled, even with the .intentional. interpretation. Regards Axel Von: Ed Willink [mailto:ed@willink.me.uk] Gesendet: Mittwoch, 8. Mai 2013 22:01 An: uml25-ftf@omg.org Betreff: Re: Resolution 6464 - doubts Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com[mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6308 - Release Date: 05/08/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6309 - Release Date: 05/08/13