Issue 12582: OCL 2.0 8.2 Collection Type packaging (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: [Pending a resolution of Issue 10946] In order to use a collection type, it is is necessary to define that type and provide some container for it. OCL provides no guidance on what that container should be, or upon what the relative semantics of A::Set(E) is with respect to B::Set(E). QVT 1.0 has defined all CollectionType(ElementType) to be the same type regardless of the accidental package used for their containment. OCL should adopt the QVT definition (even if 10946 is adopted). Resolution: Resolution of issue 9171 contains an statement saying that collection instances may be in different containers and still represent the same type. Disposition: See issue 9171 for disposition Revised Text: In the preamble of Section 8.2, after sentence " Conceptually all these types do exist, but such a type should be (lazily) instantiated by a tool, whenever it is needed in an expression. " add the sentence: For convenience an instance representing a collection type or a tuple type may be replicated in different namespaces (such as in a top-level package or within the expression referencing it) , however they represent semantically the same type. Actions taken: July 19, 2008: received issue October 16, 2009: closed issue Discussion: A sentence is needed to state that collection types can be replicated in different namespaces and still represent the same type. This is in line with 10946 resolution. End of Annotations:===== m: "Ed Willink" To: Subject: OCL 2.0 8.2 Collection Type packaging Date: Sat, 19 Jul 2008 08:32:02 +0100 X-Mailer: Microsoft Outlook, Build 10.0.6838 Thread-Index: AcjpcYkiEfPBz3OKQPazumBG+YS3ug== X-Plusnet-Relay: 8f4af01cc4f38dd8d4aa4b05db3dba18 [Pending a resolution of Issue 10946] In order to use a collection type, it is is necessary to define that type and provide some container for it. OCL provides no guidance on what that container should be, or upon what the relative semantics of A::Set(E) is with respect to B::Set(E). QVT 1.0 has defined all CollectionType(ElementType) to be the same type regardless of the accidental package used for their containment. From: "Christian W. Damus" To: Juergen Boldt Subject: Re: issue 12582 -- OCL 2 RTF issue Date: Tue, 7 Oct 2008 09:45:49 -0400 X-Mailer: Apple Mail (2.929.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s014.panelboxmanager.com X-AntiAbuse: Original Domain - omg.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zeligsoft.com X-Source: X-Source-Args: X-Source-Dir: I support this proposal. In my proposal on Issue 10946, I suggested that the ExpressionInOcl should own these demand-created collection types (and others). This equivalence proposal resolves the replication that would result from multiple expressions defining the same collection types. Cheers, Christian On 29-Jul-08, at 1:55 PM, Juergen Boldt wrote: From: "Ed Willink" To: Subject: OCL 2.0 8.2 Collection Type packaging Date: Sat, 19 Jul 2008 08:32:02 +0100 X-Mailer: Microsoft Outlook, Build 10.0.6838 Thread-Index: AcjpcYkiEfPBz3OKQPazumBG+YS3ug== X-Plusnet-Relay: 8f4af01cc4f38dd8d4aa4b05db3dba18 [Pending a resolution of Issue 10946] In order to use a collection type, it is is necessary to define that type and provide some container for it. OCL provides no guidance on what that container should be, or upon what the relative semantics of A::Set(E) is with respect to B::Set(E). QVT 1.0 has defined all CollectionType(ElementType) to be the same type regardless of the accidental package used for their containment. OCL should adopt the QVT definition (even if 10946 is adopted). Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@zeligsoft.com From: "Christian W. Damus" To: ocl2-rtf@omg.org Subject: Re: issue 12582 -- OCL 2 RTF issue Date: Tue, 7 Oct 2008 09:48:44 -0400 X-Mailer: Apple Mail (2.929.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s014.panelboxmanager.com X-AntiAbuse: Original Domain - omg.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zeligsoft.com X-Source: X-Source-Args: X-Source-Dir: Sorry, my first attempt to reply was sent to Juergen only. I support this proposal. In my proposal on Issue 10946, I suggested that the ExpressionInOcl should own these demand-created collection types (and others). This equivalence proposal resolves the replication that would result from multiple expressions defining the same collection types. Cheers, Christian On 29-Jul-08, at 1:55 PM, Juergen Boldt wrote: From: "Ed Willink" To: Subject: OCL 2.0 8.2 Collection Type packaging Date: Sat, 19 Jul 2008 08:32:02 +0100 X-Mailer: Microsoft Outlook, Build 10.0.6838 Thread-Index: AcjpcYkiEfPBz3OKQPazumBG+YS3ug== X-Plusnet-Relay: 8f4af01cc4f38dd8d4aa4b05db3dba18 [Pending a resolution of Issue 10946] In order to use a collection type, it is is necessary to define that type and provide some container for it. OCL provides no guidance on what that container should be, or upon what the relative semantics of A::Set(E) is with respect to B::Set(E). QVT 1.0 has defined all CollectionType(ElementType) to be the same type regardless of the accidental package used for their containment. OCL should adopt the QVT definition (even if 10946 is adopted). Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@zeligsoft.com OCL should adopt the QVT definition (even if 10946 is adopted).