Issue 13103: element creation and element attachment/detachment to/from an extent (qvt-rtf) Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com) Nature: Enhancement Severity: Minor Summary: Suggestion: In the Operational Mappings language, element creation and element attachment/detachment to/from an extent should be seen and treated as two different and independent activities. Once an element is created via an ObjectExp, this element is usually attached to another element immediately afterwards, which becomes its container, so the ObjectExp semantics of assigning it to an explicit or inferred extent becomes an unnecessary overhead. And also there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time. They could even exist prior to the transformation execution. A case where this is relevant is with the result of a 'Element::clone()' or 'Element::deepclone()' operation execution. Is it expected that these model elements must belong by default to the same model as the original? How to clone parts of an extent with direction kind == 'in'? How to make them become part of the Set of root elements of another, different extent? Resolution: element creation and element attachment/detachment to/from an extent Suggestion: In the Operational Mappings language, element creation and element attachment/detachment to/from an extent should be seen and treated as two different and independent activities. Once an element is created via an ObjectExp, this element is usually attached to another element immediately afterwards, which becomes its container, so the ObjectExp semantics of assigning it to an explicit or inferred extent becomes an unnecessary overhead. And also there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time. They could even exist prior to the transformation execution. A case where this is relevant is with the result of a 'Element::clone()' or 'Element::deepclone()' operation execution. Is it expected that these model elements must belong by default to the same model as the original? How to clone parts of an extent with direction kind == 'in'? How to make them become part of the Set of root elements of another, different extent? Discussion This seems to be a misunderstanding. ObjectExp does not require a created object to be attached to an inferred extent. This functionality seems to be present already. Creation without attachment requires a null or null-valued extent during creation. Attachment after creation can occur through an ObjectExp update to the required extent. Re-attachment presumably occurs through an ObjectExp update to the new extent. Detachment then naturally occurs through an ObjectExp update to a null-valued extent. This issue inspired the provision of a better desciption of extents. The resolution is therefore merged with that of [1]QVT-36. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/QVT-36 Revised Text: Actions taken: November 21, 2008: received issue December 22, 2015: Duplicate or Merged March 29, 2016: closed issue Discussion: This seems to be a misunderstanding. ObjectExp does not require a created object to be attached to an inferred extent. This functionality seems to be present already. Creation without attachment requires a null or null-valued extent during creation. Attachment after creation can occur through an ObjectExp update to the required extent. Re-attachment presumably occurs through an ObjectExp update to the new extent. Detachment then naturally occurs through an ObjectExp update to a null-valued extent. Preview Revised Text: In 8.2.1.24 ObjectExp add after the first paragraph Object creation, initialisation and residence are separate activities. Object creation occurs when the referredObject has a null value; it is skipped if the referredObject variable references an existing object. Object initialization always occurs, but may be trivial if the body is empty. Object residence is left unchanged when the extent is omitted, so object creation will normally result in an object without any residence; the residence will be established as soon as the created object is put at the target end of some composition relationship. An explicit object residence may be established by specifying the model parameter for the required extent as the extent. Specifying an extent with a null value ensures that the created object has no residence; this may remove the residence of a pre-existing object. Discussion Discussion, primarily on Eclipse qvto-dev identified the lack of an overview of the intent of an Extent to motivate the detailed behaviours amended above in ObjectExp but not revised for InstantiationExp. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 21 Nov 2008 15:50:31 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: E. Victor Sánchez Company: Open Canarias S.L. mailFrom: vsanchez@opencanarias.com Notification: Yes Specification: MOF QVT Section: 8.2.1.24 FormalNumber: formal/2008-04-03 Version: 1.0 RevisionDate: 04/03/2008 Page: 86-87 Nature: Enhancement Severity: Minor HTTP User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) Gecko/2008111317 Ubuntu/8.04 (hardy) Firefox/3.0.4 Description Suggestion: In the Operational Mappings language, element creation and element attachment/detachment to/from an extent should be seen and treated as two different and independent activities. Once an element is created via an ObjectExp, this element is usually attached to another element immediately afterwards, which becomes its container, so the ObjectExp semantics of assigning it to an explicit or inferred extent becomes an unnecessary overhead. And also there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time. They could even exist prior to the transformation execution. A case where this is relevant is with the result of a 'Element::clone()' or 'Element::deepclone()' operation execution. Is it expected that these model elements must belong by default to the same model as the original? How to clone parts of an extent with direction kind == 'in'? How to make them become part of the Set of root elements of another, different extent? Sender: Victor Sanchez Date: Thu, 08 Jan 2009 14:05:37 +0000 From: Victor Sanchez User-Agent: Thunderbird 2.0.0.18 (X11/20081125) To: qvt-rtf@omg.org Subject: Concerning Issue 13103 X-Enigmail-Version: 0.95.0 Hello, guys! It's Victor Sánchez, a colleague of Adolfo's in Open Canarias. I just wanted to point out that when I submitted QVT's Issue #13103 last year, I did not mention any suggestions to solve the stated problem. I don't know how to update that issue to include suggestion information. I'm afraid I cannot do that. The contents of the submitted issue follows: ************************************ In the Operational Mappings language, element creation and element attachment/detachment to/from an extent should be seen and treated as two different and independent activities. Once an element is created via an ObjectExp, this element is usually attached to another element immediately afterwards, which becomes its container, so the ObjectExp semantics of assigning it to an explicit or inferred extent becomes an unnecessary overhead. And also there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time. They could even exist prior to the transformation execution. A case where this is relevant is with the result of a 'Element::clone()' or 'Element::deepclone()' operation execution. Is it expected that these model elements must belong by default to the same model as the original? How to clone parts of an extent with direction kind == 'in'? How to make them become part of the Set of root elements of another, different extent? ************************************ A possible solution, which is attached here below, was proposed by Mariano Belaunde via personal mail: ************************************ Currently in a mapping operation or in an explicit object expression, if you do not indicate the extent, then by default the newly created object is automatically inserted to an inferred extent. We could imagine a different rule: in order for a created element to be inserted into an extent, make it explicit. Like in: mapping A::foo() : X@myextent { ... } x := object X@myextent { ... } We could also add a 'insertElement()' operation, in the cases where the inclusion to an extent has to be performed at a different time. ************************************ Thank you very much and sorry for any inconveniencies this might cause. Cheers!!! Victor Sanchez Open Canarias S.L. C/. Elías Ramos González, 4. Ofic. 304 38001 S/C de Tenerife - Spain Telf: +34 922 240 231 Date: Thu, 30 Apr 2009 13:26:52 -0430 Subject: [Issue 13103] From: Victor Sanchez To: qvt-rtf@omg.org Hello! It's been more than three months and I do not know if my previous mail sent about Issue 13103 was taken into account. I'd expect the following text to be appended to the contents of the issue: ************************************ Solution suggested by Mr. Mariano Belaunde: Currently in a mapping operation or in an explicit object expression, if you do not indicate the extent, then by default the newly created object is automatically inserted to an inferred extent. We could imagine a different rule: in order for a created element to be inserted into an extent, make it explicit. Like in: mapping A::foo() : X@myextent { ... } x := object X@myextent { ... } We could also add a 'insertElement()' operation, in the cases where the inclusion to an extent has to be performed at a different time. ************************************ Thanks in advance! Victor 2009/1/8 Victor Sanchez Hello, guys! It's Victor Sánchez, a colleague of Adolfo's in Open Canarias. I just wanted to point out that when I submitted QVT's Issue #13103 last year, I did not mention any suggestions to solve the stated problem. I don't know how to update that issue to include suggestion information. I'm afraid I cannot do that. The contents of the submitted issue follows: ************************************ In the Operational Mappings language, element creation and element attachment/detachment to/from an extent should be seen and treated as two different and independent activities. Once an element is created via an ObjectExp, this element is usually attached to another element immediately afterwards, which becomes its container, so the ObjectExp semantics of assigning it to an explicit or inferred extent becomes an unnecessary overhead. And also there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time. They could even exist prior to the transformation execution. A case where this is relevant is with the result of a 'Element::clone()' or 'Element::deepclone()' operation execution. Is it expected that these model elements must belong by default to the same model as the original? How to clone parts of an extent with direction kind == 'in'? How to make them become part of the Set of root elements of another, different extent? ************************************ A possible solution, which is attached here below, was proposed by Mariano Belaunde via personal mail: ************************************ Currently in a mapping operation or in an explicit object expression, if you do not indicate the extent, then by default the newly created object is automatically inserted to an inferred extent. We could imagine a different rule: in order for a created element to be inserted into an extent, make it explicit. Like in: mapping A::foo() : X@myextent { ... } x := object X@myextent { ... } We could also add a 'insertElement()' operation, in the cases where the inclusion to an extent has to be performed at a different time. ************************************ Thank you very much and sorry for any inconveniencies this might cause. Cheers!!! Victor Sanchez Open Canarias S.L. C/. Elías Ramos González, 4. Ofic. 304 38001 S/C de Tenerife - Spain Telf: +34 922 240 231 Fax: +34 922 247 553 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=KvrD2AmN c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=U5aTihw9y_sA:10 a=EgeY-4M5PEwA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=z-54A8CZie8A:10 a=JIVOxcAaAAAA:8 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=Xn-YNOqcfqJBiFZArwkA:9 a=u9Uoy2vOz1hTqOQG:21 a=LFTmiFXajHheGyGx:21 a=wPNLvfGTeEIA:10 a=R4QD78S-XS0A:10 a=WP4_USCxRkkA:10 Date: Tue, 04 Feb 2014 11:27:06 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: QVTD developers mailing list , "qvt-rtf@omg.org" Subject: Issue 13103 - Element creation/attachmenty/detachment (was Re: AW: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2) X-Virus-Scanned: amavisd-new at omg.org Hi Christopher Issue 13103 was originally on my helpwanted list, but in the absence of any help, it was one where I thought I could take a shot at it using my intuition. At least it has now provoked some discussion, so we can discuss if - I'm right and the proposed resolution stands - it is easily corrected so we modify it - we want a more prolonged discussion/research and the resolution is withdrawn. No need for a new OMG issue while an existing one is still open. In Eclipse terms, I interpret residence in an extent as being locateable by Resource.eAllContents(), so for any EObject the extent is just eObject.eResource() [or more pedantically to handle fragmented resources: EcoreUtil.getRootContainer(eObject).eResource()]. Objects created without any residence have a null eResource() and so may be lost. In the case of mapping results, indeed the mapping has no effect on residence, but since the mapping result is often assigned to a composition, that assignment changes the residence. The issue addressed only ObjectExp, but if we should extend it to InstantiationExp then lets do so. Please suggest words. Regards Ed Willink On 04/02/2014 10:37, Christopher Gerking wrote: Hi Ed & Adolfo I'm not yet convinced by the resolution for issue 13103: element creation and element attachment/detachment to/from an extent. The proposed resolution targets ObjectExp only. Applying the "short form" to "long form" conversion rules, I expect that the proposed behavior holds for mappings as well. However, does this imply that elements are attached to an extent only on creation, and not reattached whenever they act as a mapping result? To clarify this hehavior, I already raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=425066 for Eclipse QVTo. Without reattaching, there seems to be no reasonable way of adding an element created inside a blackbox to an extent. Adolfo already pointed at the same issue: "there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time." For the clone/deepclone operations, I just found out that Eclipse QVTo does not behave as described by Adolfo. It does not add the clones to the same extent as the original, but always obtains the proper "default" extent. Do we require a new OMG issue? Regards Christopher -----Ursprühe Nachricht----- Von: qvto-dev-bounces@eclipse.org [mailto:qvto-dev-bounces@eclipse.org] Im Auftrag von Ed Willink Gesendet: Montag, 3. Februar 2014 20:02 An: qvt-rtf@omg.org; QVTOML developer mailing list Betreff: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2 Hi Note that voting for Ballot 1 reballot is still open. Please vote. Note that voting for Ballot 2 is still open. Please vote. The second preview of QVT 1.2 RTF Ballot 3 is attached (with change bars since Preview 1). Preview 30-Jan to 5-Feb Voting 5-Feb to 19-Feb Most of the working material may be found at http://svn.omg.org/repos/QVT/trunk/Documents/TaskForces/1.2. Apply to Juergen for a password, and beware of using SVN 1.8 tooling for the 1.4 server (1.7 seems fine). I have managed to provide simple resolutions to two previously deferred issues. Issue 12518 is substantially updated to include the redrawn Papyrus diagrams. The provisional Ecore and UML models and Papyrus diagrams can be found in http://svn.omg.org/repos/QVT/trunk/Documents/Specifications/1.2/Models Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3684/7058 - Release Date: 02/03/14 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=A7jCitjsxGzA9TOjfCLGsywXRCniq0ywuOMldNVw5bA=; b=LYFNZzOUpd/fgztN3JG8jBA4XB5aWJfkmnP2bLuya7oA6yh4CP9J3AoHqVd9PRYRSk UYXYeSz1awf2OWVwrW7cppAtdckzMAbJ6O0QeHz4G8KwYbVNNy4Clu6LBpPue89sAbdz oUX1tqnyLstBES2bniJRHfz4zLSXd+KvkaElb+YgZn6oKxyzZiK+gBWxDJWTq5NF0wlL /S+qkpE21suCK/5/JGeRxtW71O+wvCLEhcGWTK8EwZjYVolMFYx1iS5nW9/AFmxia+q2 pjSDXK2jV+ZatKtMOjmk5MMmfKen3RVRZKx9h9QfDrB+nH+22RZn1Vj5p2+CXyzBhTZh D3Yg== X-Gm-Message-State: ALoCoQnRtoAJP1tSM6MVtWaZGhmzIKm7VzJKMYw9hbfvJkSlLVzhnH0OfPeslNQFYtv+Sy25dYry X-Received: by 10.194.119.168 with SMTP id kv8mr2432014wjb.41.1391624985467; Wed, 05 Feb 2014 10:29:45 -0800 (PST) Sender: Adolfo Sanchez Barbudo Date: Wed, 05 Feb 2014 18:29:42 +0000 From: Adolfo Sáhez-Barbudo Herrera Organization: Open Canarias S.L. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11 To: Ed Willink CC: QVTOML developer mailing list , "qvt-rtf@omg.org" Subject: Re: Issue 13103 - Element creation/attachmenty/detachment (was Re: AW: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2) X-Virus-Scanned: amavisd-new at omg.org Hi All, I endeavour to revise 13103 resolution (otherwise vote NO to it). I can grasp a two claims by the issue sender: 1. ObjectExp::extent is an unnecessary overhead because they are usually attached to a different container. Indeed, it's usually an "overhead", but ... it's necessary because it's the only way that the ObjectExp construct has to attach created objects to an specific model extent (as root elements). 2. There is not way to specify a model extent when using the clone/deepClone library operations. Actually the specification says nothing about where the cloned object resides (in the same model extent of the clonned object? no residence ?) I don't think that the resolution address the issues. Instead it creates a new one, in particular with the claim: "An explicit object residence may be established by specifying the model parameter for the required extent as the extent" Both the resolution, and suggested revised text lead to the interpretation that an object may change its residence even though the object existed before (when referredObject != null). This is a bad idea. With respect to the extent, the specification vaguely (but repeatedly) states that the residence is established upon creation only. For instance see: Section 8.2.1.16. "The extent of the mapping parameter. If not provided, the extent is inferred by inspecting the model types of the transformation. See the inference rules below. Should be explicitly provided when there is an ambiguity on the extent to own the potential created element corresponding to this parameter." Section 8.2.1.24 "References a model parameter where the object should reside in case it is instantiated. This is optional." With all of this, in order to solve issue claim 2 and to avoid the problem introduced by the current resolution, I propose a new text for the issue resolution at the end of the email. Regards, Adolfo. ---- Resolution: Indeed, specification doesn't clarify to which extent the cloned elements belong to. There is no way to assign cloned elements to an specific model extent neither. Add a clone/deepclone version which accepts a model extent. For completeness add a Model::addElement operation. To be aligned with addElement description, sensibly add some text with the aim to prevent calls to removeElement on an model parameter declared as "in" model parameter. Indeed, ObjectExp::extent is *usually* an overhead when they are normally attached to a different container. However, unlike MappingParameters, the extent is not stated to be inferred, so if there is an overhead is because the transformation writer has explicitly coded so (using the @modelExtent syntax). Similarly to the clone/deepClone concern, this extent is currently necessary because there is not other way to assign the created element to a model extent. Revised Text: In 8.2.1.24 ObjectExp add after the first paragraph Object creation, initialisation and residence are separate activities. Object creation occurs when the referredObject has a null value; it is skipped if the referredObject variable references an existing object. Object initialization always occurs, but may be trivial if the body is empty. When a new object is created, its residence will occur in the model parameter referred by the extent association. When the extent is omitted, object creation will normally result in an object without any residence; the residence will be established as soon as the created object is put at the target end of some composition relationship. When no object is created, no residence change occurs even though an extent is defined. In 8.3.4.10 add after the first paragraph The element returned by this operation will not reside in any model extent. It's a responsibility of the caller to proper attach the created cloned element to a proper container. Element::clone(Model modelExtent) : Element Creates and returns a copy of a model element. Copy is done only at first level (sub objects are not cloned). References to non contained objects are copied only if the multiplicity constraints are not violated. The element returned by this operation will reside in the given modelExtent. It's not allowed to provide a modelExtent declared as an "in" transformation model parameter. In 8.3.4.11 add after the first paragraph The element returned by this operation will not reside in any model extent. It's a responsibility of the caller to proper attach the created cloned element to a proper container. Element::deepclone(Model modelExtent) : Element Creates and returns a deep copy of a model element. Copy is done recursively on sub objects. References to non contained objects are copied only if the multiplicity constraints are not violated. The element returned by this operation will reside in the given modelExtent. It's not allowed to provide a modelExtent declared as an "in" transformation model parameter. In 8.3.5.4. add after the first paragraph It's not allowed to invoke this operation on a model extent declared as an "in" transformation model parameter. After 8.3.5.4 add the new Model operation 8.3.5.5 addElement Model::addElement (Element element): OclVoid Adds the given element to the modelExtent. This element will be new element added to the existing root elements of the model extent. It's not allowed to invoke this operation on a model extent declared as an "in" transformation model parameter. Disposition: Resolved On 04/02/2014 11:27, Ed Willink wrote: Hi Christopher Issue 13103 was originally on my helpwanted list, but in the absence of any help, it was one where I thought I could take a shot at it using my intuition. At least it has now provoked some discussion, so we can discuss if - I'm right and the proposed resolution stands - it is easily corrected so we modify it - we want a more prolonged discussion/research and the resolution is withdrawn. No need for a new OMG issue while an existing one is still open. In Eclipse terms, I interpret residence in an extent as being locateable by Resource.eAllContents(), so for any EObject the extent is just eObject.eResource() [or more pedantically to handle fragmented resources: EcoreUtil.getRootContainer(eObject).eResource()]. Objects created without any residence have a null eResource() and so may be lost. In the case of mapping results, indeed the mapping has no effect on residence, but since the mapping result is often assigned to a composition, that assignment changes the residence. The issue addressed only ObjectExp, but if we should extend it to InstantiationExp then lets do so. Please suggest words. Regards Ed Willink On 04/02/2014 10:37, Christopher Gerking wrote: Hi Ed & Adolfo I'm not yet convinced by the resolution for issue 13103: element creation and element attachment/detachment to/from an extent. The proposed resolution targets ObjectExp only. Applying the "short form" to "long form" conversion rules, I expect that the proposed behavior holds for mappings as well. However, does this imply that elements are attached to an extent only on creation, and not reattached whenever they act as a mapping result? To clarify this hehavior, I already raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=425066 for Eclipse QVTo. Without reattaching, there seems to be no reasonable way of adding an element created inside a blackbox to an extent. Adolfo already pointed at the same issue: "there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time." For the clone/deepclone operations, I just found out that Eclipse QVTo does not behave as described by Adolfo. It does not add the clones to the same extent as the original, but always obtains the proper "default" extent. Do we require a new OMG issue? Regards Christopher -----Ursprühe Nachricht----- Von: qvto-dev-bounces@eclipse.org [mailto:qvto-dev-bounces@eclipse.org] Im Auftrag von Ed Willink Gesendet: Montag, 3. Februar 2014 20:02 An: qvt-rtf@omg.org; QVTOML developer mailing list Betreff: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2 Hi Note that voting for Ballot 1 reballot is still open. Please vote. Note that voting for Ballot 2 is still open. Please vote. The second preview of QVT 1.2 RTF Ballot 3 is attached (with change bars since Preview 1). Preview 30-Jan to 5-Feb Voting 5-Feb to 19-Feb Most of the working material may be found at http://svn.omg.org/repos/QVT/trunk/Documents/TaskForces/1.2. Apply to Juergen for a password, and beware of using SVN 1.8 tooling for the 1.4 server (1.7 seems fine). I have managed to provide simple resolutions to two previously deferred issues. Issue 12518 is substantially updated to include the redrawn Papyrus diagrams. The provisional Ecore and UML models and Papyrus diagrams can be found in http://svn.omg.org/repos/QVT/trunk/Documents/Specifications/1.2/Models Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3684/7058 - Release Date: 02/03/14 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=WPfxXxcR c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=U5aTihw9y_sA:10 a=dwZvbWbWefcA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=URwEHa4cbn4A:10 a=JIVOxcAaAAAA:8 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=YIIpLAI-yJyE5Pq4epYA:9 a=cVDEBj2bH8k8Uuhu:21 a=1unU7SIOFioWCnf_:21 a=wPNLvfGTeEIA:10 a=R4QD78S-XS0A:10 a=WP4_USCxRkkA:10 Date: Wed, 05 Feb 2014 19:14:12 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Adolfo Sáhez-Barbudo Herrera CC: QVTOML developer mailing list , "qvt-rtf@omg.org" Subject: Re: Issue 13103 - Element creation/attachmenty/detachment (was Re: AW: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2) X-Virus-Scanned: amavisd-new at omg.org Hi 8.2.1.16 Are we leaving this in an unsatisfactory state? 8.2.1.24 Your words allow a user specified extent to be ignored. Mine do not. I don't understnad why your changes are better. clone/deepclone. We can certainly add a comment that the clone has no extent. clone(Extent)/deepClone(Extent) This seems to be bloat, particularly given addElement, and has to be duplicated for all the Collection/List/.... overloads. Model::addElement(Element) This seems like a useful addition, and makes clone(Extent) unnecessary. But it needs stronger words regarding what happens to an old extent. Unfortunately Model is not defined anywhere in the specification! We cannot add a method to it without defining it. ---- I think the lack of a Model specification clinches it. We're better off not pretending to make this any better/worse. I'll withdraw 13103 from Ballot 3, but that doesn't mean we have to stop trying to resolve it now rather than one week before a QVT 1.3 deadline. Ping me in a week if I haven't responded to your follow-up. Since we're trying to agree on words, a GoogleDoc might be good for the hopefully converging consensus. REgards Ed On 05/02/2014 18:29, Adolfo Sáhez-Barbudo Herrera wrote: Hi All, I endeavour to revise 13103 resolution (otherwise vote NO to it). I can grasp a two claims by the issue sender: 1. ObjectExp::extent is an unnecessary overhead because they are usually attached to a different container. Indeed, it's usually an "overhead", but ... it's necessary because it's the only way that the ObjectExp construct has to attach created objects to an specific model extent (as root elements). 2. There is not way to specify a model extent when using the clone/deepClone library operations. Actually the specification says nothing about where the cloned object resides (in the same model extent of the clonned object? no residence ?) I don't think that the resolution address the issues. Instead it creates a new one, in particular with the claim: "An explicit object residence may be established by specifying the model parameter for the required extent as the extent" Both the resolution, and suggested revised text lead to the interpretation that an object may change its residence even though the object existed before (when referredObject != null). This is a bad idea. With respect to the extent, the specification vaguely (but repeatedly) states that the residence is established upon creation only. For instance see: Section 8.2.1.16. "The extent of the mapping parameter. If not provided, the extent is inferred by inspecting the model types of the transformation. See the inference rules below. Should be explicitly provided when there is an ambiguity on the extent to own the potential created element corresponding to this parameter." Section 8.2.1.24 "References a model parameter where the object should reside in case it is instantiated. This is optional." With all of this, in order to solve issue claim 2 and to avoid the problem introduced by the current resolution, I propose a new text for the issue resolution at the end of the email. Regards, Adolfo. ---- Resolution: Indeed, specification doesn't clarify to which extent the cloned elements belong to. There is no way to assign cloned elements to an specific model extent neither. Add a clone/deepclone version which accepts a model extent. For completeness add a Model::addElement operation. To be aligned with addElement description, sensibly add some text with the aim to prevent calls to removeElement on an model parameter declared as "in" model parameter. Indeed, ObjectExp::extent is *usually* an overhead when they are normally attached to a different container. However, unlike MappingParameters, the extent is not stated to be inferred, so if there is an overhead is because the transformation writer has explicitly coded so (using the @modelExtent syntax). Similarly to the clone/deepClone concern, this extent is currently necessary because there is not other way to assign the created element to a model extent. Revised Text: In 8.2.1.24 ObjectExp add after the first paragraph Object creation, initialisation and residence are separate activities. Object creation occurs when the referredObject has a null value; it is skipped if the referredObject variable references an existing object. Object initialization always occurs, but may be trivial if the body is empty. When a new object is created, its residence will occur in the model parameter referred by the extent association. When the extent is omitted, object creation will normally result in an object without any residence; the residence will be established as soon as the created object is put at the target end of some composition relationship. When no object is created, no residence change occurs even though an extent is defined. In 8.3.4.10 add after the first paragraph The element returned by this operation will not reside in any model extent. It's a responsibility of the caller to proper attach the created cloned element to a proper container. Element::clone(Model modelExtent) : Element Creates and returns a copy of a model element. Copy is done only at first level (sub objects are not cloned). References to non contained objects are copied only if the multiplicity constraints are not violated. The element returned by this operation will reside in the given modelExtent. It's not allowed to provide a modelExtent declared as an "in" transformation model parameter. In 8.3.4.11 add after the first paragraph The element returned by this operation will not reside in any model extent. It's a responsibility of the caller to proper attach the created cloned element to a proper container. Element::deepclone(Model modelExtent) : Element Creates and returns a deep copy of a model element. Copy is done recursively on sub objects. References to non contained objects are copied only if the multiplicity constraints are not violated. The element returned by this operation will reside in the given modelExtent. It's not allowed to provide a modelExtent declared as an "in" transformation model parameter. In 8.3.5.4. add after the first paragraph It's not allowed to invoke this operation on a model extent declared as an "in" transformation model parameter. After 8.3.5.4 add the new Model operation 8.3.5.5 addElement Model::addElement (Element element): OclVoid Adds the given element to the modelExtent. This element will be new element added to the existing root elements of the model extent. It's not allowed to invoke this operation on a model extent declared as an "in" transformation model parameter. Disposition: Resolved On 04/02/2014 11:27, Ed Willink wrote: Hi Christopher Issue 13103 was originally on my helpwanted list, but in the absence of any help, it was one where I thought I could take a shot at it using my intuition. At least it has now provoked some discussion, so we can discuss if - I'm right and the proposed resolution stands - it is easily corrected so we modify it - we want a more prolonged discussion/research and the resolution is withdrawn. No need for a new OMG issue while an existing one is still open. In Eclipse terms, I interpret residence in an extent as being locateable by Resource.eAllContents(), so for any EObject the extent is just eObject.eResource() [or more pedantically to handle fragmented resources: EcoreUtil.getRootContainer(eObject).eResource()]. Objects created without any residence have a null eResource() and so may be lost. In the case of mapping results, indeed the mapping has no effect on residence, but since the mapping result is often assigned to a composition, that assignment changes the residence. The issue addressed only ObjectExp, but if we should extend it to InstantiationExp then lets do so. Please suggest words. Regards Ed Willink On 04/02/2014 10:37, Christopher Gerking wrote: Hi Ed & Adolfo I'm not yet convinced by the resolution for issue 13103: element creation and element attachment/detachment to/from an extent. The proposed resolution targets ObjectExp only. Applying the "short form" to "long form" conversion rules, I expect that the proposed behavior holds for mappings as well. However, does this imply that elements are attached to an extent only on creation, and not reattached whenever they act as a mapping result? To clarify this hehavior, I already raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=425066 for Eclipse QVTo. Without reattaching, there seems to be no reasonable way of adding an element created inside a blackbox to an extent. Adolfo already pointed at the same issue: "there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time." For the clone/deepclone operations, I just found out that Eclipse QVTo does not behave as described by Adolfo. It does not add the clones to the same extent as the original, but always obtains the proper "default" extent. Do we require a new OMG issue? Regards Christopher -----Ursprühe Nachricht----- Von: qvto-dev-bounces@eclipse.org [mailto:qvto-dev-bounces@eclipse.org] Im Auftrag von Ed Willink Gesendet: Montag, 3. Februar 2014 20:02 An: qvt-rtf@omg.org; QVTOML developer mailing list Betreff: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2 Hi Note that voting for Ballot 1 reballot is still open. Please vote. Note that voting for Ballot 2 is still open. Please vote. The second preview of QVT 1.2 RTF Ballot 3 is attached (with change bars since Preview 1). Preview 30-Jan to 5-Feb Voting 5-Feb to 19-Feb Most of the working material may be found at http://svn.omg.org/repos/QVT/trunk/Documents/TaskForces/1.2. Apply to Juergen for a password, and beware of using SVN 1.8 tooling for the 1.4 server (1.7 seems fine). I have managed to provide simple resolutions to two previously deferred issues. Issue 12518 is substantially updated to include the redrawn Papyrus diagrams. The provisional Ecore and UML models and Papyrus diagrams can be found in http://svn.omg.org/repos/QVT/trunk/Documents/Specifications/1.2/Models Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3684/7058 - Release Date: 02/03/14 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3684/7065 - Release Date: 02/05/14 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=r831EQ6u4S6gw3UeV+xSQgUezeALAalWbmen7APbIgM=; b=ZNaKsxWdMyMEmqDCNCe9ZAgvPJuUvqgMTUgHWhO0SGA2elktCi7yG4WCzimKETTMhb LoolNgtiTXF5uXgXAbUzKrGXadF066UD0j8QP7mqkt3fBKU0DO2X44i3JoT5xV4ygguS U/jWmKPvePUIB+26xhD3W1NUDLaFbI+PqSlq35I8SurOdj/svuDjqU1qQtnbIsh9ZIkW Tws9Aq6CPTsNTOKz7P9AkGKXt+S/45QnE2AWUBxPW0KErWZZsnLljF9SMBvhAYe7RMVa ZmjzaMQrOikKBCN0Hp6wZi5+K0WwdK9ONpYtjYMBoqfnKNN74aoBqfR+Hy/bOS6yPICf ubBA== X-Gm-Message-State: ALoCoQll4HpuQT/PwHZ/kMs6RXbrMn2uIgPglrExLUlfrV2Uz1Q7JkBCsf0Fpm3JSirqR6D9GVcY X-Received: by 10.181.11.169 with SMTP id ej9mr18496809wid.18.1391630679593; Wed, 05 Feb 2014 12:04:39 -0800 (PST) Sender: Adolfo Sanchez Barbudo Date: Wed, 05 Feb 2014 20:04:37 +0000 From: Adolfo Sáhez-Barbudo Herrera Organization: Open Canarias S.L. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11 To: Ed Willink CC: QVTOML developer mailing list , "qvt-rtf@omg.org" Subject: Re: Issue 13103 - Element creation/attachmenty/detachment (was Re: AW: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2) X-Virus-Scanned: amavisd-new at omg.org On 05/02/2014 19:14, Ed Willink wrote: Hi 8.2.1.16 Are we leaving this in an unsatisfactory state? Yes. Just focusing on the issue to avoid other concerns and focusing on the real problem. See the follow up thread for those "other concerns". 8.2.1.24 Your words allow a user specified extent to be ignored. Mine do not. I don't understnad why your changes are better. Ignored in case the object already "existed", taking into account the already existent elements is the real problem of the ballot 3 resolution. IMHO is better because: 1. Is consistent with the specification, which explicitly mention the extent upon creation: -8.2.2.23 InstantiationExp::extent : Variable [0..1] The extent on which the new object is created. -8.2.1.24 ObjectExp::/extent: Variable [0..1] References a model parameter where the object should reside in case it is instantiated. This is optional. Also applying the residence change to already existent objects is the bit you are changing, without apparent justification, and what I want to prevent to occur. 2. Allowing an object to be moved from its container is a very DANGEROUS facility, specially giving the nature of mapping extensions. Having this dangerous behaviour depending on the evaluation (runtime!) of the ObjectExp variable (referredObject) is a hazardous language design decision. clone/deepclone. We can certainly add a comment that the clone has no extent. clone(Extent)/deepClone(Extent) This seems to be bloat, particularly given addElement, and has to be duplicated for all the Collection/List/.... overloads. With the Model::addElement(Element) the "extent" stuff could also be bloat as well >.< It's for completeness and handful activity. I usually think of cloning an element and on the fly decide if I pass the extent, not the other way. In the end is a matter of syntax element.clone(outputModel) vs outputModel.addElement(element.clone()) Note that the following also fix the issue: Model::cloneElement(Element) However, you work on the element, and then you think of assigning to a model extent. Anyway, this is not mandatory to solve the resolution, so as the RTF decide. Model::addElement(Element) This seems like a useful addition, and makes clone(Extent) unnecessary. But it needs stronger words regarding what happens to an old extent. Which old extent?. The model element should either a) not belong to any model extent, so no problem. b) belong to a model extent, as a root element or contained in any other inner model element. It's removed from the container an added to the new modelExtent as a root element. But!!! What if we add an already (inner) contained element to the same model extent that it belongs to ?. It still needs clarification: a) Either the object is not removed from its container. b) Or it's removed from it and then added as an root model element of the same model extent. Unfortunately Model is not defined anywhere in the specification! We cannot add a method to it without defining it. It's mentioned at 8.3.1.2, as an M1 type (instance of ModelType) to provide the library operation. I haven't thought about that, but in any case it's a different issue. ---- I think the lack of a Model specification clinches it. We're better off not pretending to make this any better/worse. The resolution is consistent with the current specification state, and IMO better than the previous one, but... see below I'll withdraw 13103 from Ballot 3, but that doesn't mean we have to stop trying to resolve it now rather than one week before a QVT 1.3 deadline. Ping me in a week if I haven't responded to your follow-up. Since we're trying to agree on words, a GoogleDoc might be good for the hopefully converging consensus. You are the chairman. I'm just a third eye. If you prefer the withdrawal (which seems fair since Manfred has already vote YES for the previous resolution) sound good to me. Regards, Adolfo. REgards Ed On 05/02/2014 18:29, Adolfo Sáhez-Barbudo Herrera wrote: Hi All, I endeavour to revise 13103 resolution (otherwise vote NO to it). I can grasp a two claims by the issue sender: 1. ObjectExp::extent is an unnecessary overhead because they are usually attached to a different container. Indeed, it's usually an "overhead", but ... it's necessary because it's the only way that the ObjectExp construct has to attach created objects to an specific model extent (as root elements). 2. There is not way to specify a model extent when using the clone/deepClone library operations. Actually the specification says nothing about where the cloned object resides (in the same model extent of the clonned object? no residence ?) I don't think that the resolution address the issues. Instead it creates a new one, in particular with the claim: "An explicit object residence may be established by specifying the model parameter for the required extent as the extent" Both the resolution, and suggested revised text lead to the interpretation that an object may change its residence even though the object existed before (when referredObject != null). This is a bad idea. With respect to the extent, the specification vaguely (but repeatedly) states that the residence is established upon creation only. For instance see: Section 8.2.1.16. "The extent of the mapping parameter. If not provided, the extent is inferred by inspecting the model types of the transformation. See the inference rules below. Should be explicitly provided when there is an ambiguity on the extent to own the potential created element corresponding to this parameter." Section 8.2.1.24 "References a model parameter where the object should reside in case it is instantiated. This is optional." With all of this, in order to solve issue claim 2 and to avoid the problem introduced by the current resolution, I propose a new text for the issue resolution at the end of the email. Regards, Adolfo. ---- Resolution: Indeed, specification doesn't clarify to which extent the cloned elements belong to. There is no way to assign cloned elements to an specific model extent neither. Add a clone/deepclone version which accepts a model extent. For completeness add a Model::addElement operation. To be aligned with addElement description, sensibly add some text with the aim to prevent calls to removeElement on an model parameter declared as "in" model parameter. Indeed, ObjectExp::extent is *usually* an overhead when they are normally attached to a different container. However, unlike MappingParameters, the extent is not stated to be inferred, so if there is an overhead is because the transformation writer has explicitly coded so (using the @modelExtent syntax). Similarly to the clone/deepClone concern, this extent is currently necessary because there is not other way to assign the created element to a model extent. Revised Text: In 8.2.1.24 ObjectExp add after the first paragraph Object creation, initialisation and residence are separate activities. Object creation occurs when the referredObject has a null value; it is skipped if the referredObject variable references an existing object. Object initialization always occurs, but may be trivial if the body is empty. When a new object is created, its residence will occur in the model parameter referred by the extent association. When the extent is omitted, object creation will normally result in an object without any residence; the residence will be established as soon as the created object is put at the target end of some composition relationship. When no object is created, no residence change occurs even though an extent is defined. In 8.3.4.10 add after the first paragraph The element returned by this operation will not reside in any model extent. It's a responsibility of the caller to proper attach the created cloned element to a proper container. Element::clone(Model modelExtent) : Element Creates and returns a copy of a model element. Copy is done only at first level (sub objects are not cloned). References to non contained objects are copied only if the multiplicity constraints are not violated. The element returned by this operation will reside in the given modelExtent. It's not allowed to provide a modelExtent declared as an "in" transformation model parameter. In 8.3.4.11 add after the first paragraph The element returned by this operation will not reside in any model extent. It's a responsibility of the caller to proper attach the created cloned element to a proper container. Element::deepclone(Model modelExtent) : Element Creates and returns a deep copy of a model element. Copy is done recursively on sub objects. References to non contained objects are copied only if the multiplicity constraints are not violated. The element returned by this operation will reside in the given modelExtent. It's not allowed to provide a modelExtent declared as an "in" transformation model parameter. In 8.3.5.4. add after the first paragraph It's not allowed to invoke this operation on a model extent declared as an "in" transformation model parameter. After 8.3.5.4 add the new Model operation 8.3.5.5 addElement Model::addElement (Element element): OclVoid Adds the given element to the modelExtent. This element will be new element added to the existing root elements of the model extent. It's not allowed to invoke this operation on a model extent declared as an "in" transformation model parameter. Disposition: Resolved On 04/02/2014 11:27, Ed Willink wrote: Hi Christopher Issue 13103 was originally on my helpwanted list, but in the absence of any help, it was one where I thought I could take a shot at it using my intuition. At least it has now provoked some discussion, so we can discuss if - I'm right and the proposed resolution stands - it is easily corrected so we modify it - we want a more prolonged discussion/research and the resolution is withdrawn. No need for a new OMG issue while an existing one is still open. In Eclipse terms, I interpret residence in an extent as being locateable by Resource.eAllContents(), so for any EObject the extent is just eObject.eResource() [or more pedantically to handle fragmented resources: EcoreUtil.getRootContainer(eObject).eResource()]. Objects created without any residence have a null eResource() and so may be lost. In the case of mapping results, indeed the mapping has no effect on residence, but since the mapping result is often assigned to a composition, that assignment changes the residence. The issue addressed only ObjectExp, but if we should extend it to InstantiationExp then lets do so. Please suggest words. Regards Ed Willink On 04/02/2014 10:37, Christopher Gerking wrote: Hi Ed & Adolfo I'm not yet convinced by the resolution for issue 13103: element creation and element attachment/detachment to/from an extent. The proposed resolution targets ObjectExp only. Applying the "short form" to "long form" conversion rules, I expect that the proposed behavior holds for mappings as well. However, does this imply that elements are attached to an extent only on creation, and not reattached whenever they act as a mapping result? To clarify this hehavior, I already raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=425066 for Eclipse QVTo. Without reattaching, there seems to be no reasonable way of adding an element created inside a blackbox to an extent. Adolfo already pointed at the same issue: "there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time." For the clone/deepclone operations, I just found out that Eclipse QVTo does not behave as described by Adolfo. It does not add the clones to the same extent as the original, but always obtains the proper "default" extent. Do we require a new OMG issue? Regards Christopher -----Ursprühe Nachricht----- Von: qvto-dev-bounces@eclipse.org [mailto:qvto-dev-bounces@eclipse.org] Im Auftrag von Ed Willink Gesendet: Montag, 3. Februar 2014 20:02 An: qvt-rtf@omg.org; QVTOML developer mailing list Betreff: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2 Hi Note that voting for Ballot 1 reballot is still open. Please vote. Note that voting for Ballot 2 is still open. Please vote. The second preview of QVT 1.2 RTF Ballot 3 is attached (with change bars since Preview 1). Preview 30-Jan to 5-Feb Voting 5-Feb to 19-Feb Most of the working material may be found at http://svn.omg.org/repos/QVT/trunk/Documents/TaskForces/1.2. Apply to Juergen for a password, and beware of using SVN 1.8 tooling for the 1.4 server (1.7 seems fine). I have managed to provide simple resolutions to two previously deferred issues. Issue 12518 is substantially updated to include the redrawn Papyrus diagrams. The provisional Ecore and UML models and Papyrus diagrams can be found in http://svn.omg.org/repos/QVT/trunk/Documents/Specifications/1.2/Models Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3684/7058 - Release Date: 02/03/14 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3684/7065 - Release Date: 02/05/14 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=KvrD2AmN c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=U5aTihw9y_sA:10 a=dwZvbWbWefcA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=URwEHa4cbn4A:10 a=8XP4EWq2C9QtaIRmIRUA:9 a=wPNLvfGTeEIA:10 Date: Thu, 06 Feb 2014 06:05:59 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: QVTOML developer mailing list , "qvt-rtf@omg.org" Subject: Re: Issue 13103 - Element creation/attachmenty/detachment (was Re: AW: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2) X-Virus-Scanned: amavisd-new at omg.org Hi Resurrected from the OMG mail archives: ************************************ Solution suggested by Mr. Mariano Belaunde: Currently in a mapping operation or in an explicit object _expression_, if you do not indicate the extent, then by default the newly created object is automatically inserted to an inferred extent. We could imagine a different rule: in order for a created element to be inserted into an extent, make it explicit. Like in: mapping A::foo() : X@myextent { ... } x := object X@myextent { ... } We could also add a 'insertElement()' operation, in the cases where the inclusion to an extent has to be performed at a different time. ************************************ Regards Ed Willink X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=MDvCNKnTtJgttfTyMwjUMQvOfbyJevaqFogekI1r4/8=; b=Nh+0Ce0k0XyWmqccSB2OI7ZtsDeY8SR4op3GmB9iODrAAg/VAome54fOblJHMtKoxp xUxuD3rTVBRft91kuQAEgau40DAC8t5I4NjSUCdFfMzuvmVa1kl/PeF36nAJCL7wt2zv /Ua1oe0fF5cRbzScBTLFxNE2tfoEUdAfAkZXO7xlnfhvcqresp6tSMj4C6XDZE9Vk4n9 AZXi2j4StjZpfwybLx7ZDE/vKyc3r/hdlnNZCQXAn2x7eRb2ex2tB4onvf2zx2XZoV+T JdUTVb3jycrUkY77Icfcqj90aYDJ+FbPjGJaxhpfF0mXgPwJaPUxgOQLXUtsKO5j632F +rDA== X-Gm-Message-State: ALoCoQlZ5DGy1sj/1+m3FHT4rqXwxkEjmQ3L4k5iPqYzOLLVcZbPsieZuKqgNX0zhyqU6EyFjqUk X-Received: by 10.194.142.170 with SMTP id rx10mr5195728wjb.13.1391681790009; Thu, 06 Feb 2014 02:16:30 -0800 (PST) Sender: Adolfo Sanchez Barbudo Date: Thu, 06 Feb 2014 10:16:27 +0000 From: Adolfo Sáhez-Barbudo Herrera Organization: Open Canarias S.L. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11 To: Ed Willink CC: QVTOML developer mailing list , "qvt-rtf@omg.org" Subject: Re: Issue 13103 - Element creation/attachmenty/detachment (was Re: AW: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2) X-Virus-Scanned: amavisd-new at omg.org Hi Ed, After a new look through, the specification only mention extents inference rules on mapping parameters (of a mapping operation). So, the comment is not accurate with respect to ObjectExps. In any case, the resolution for issue 13103 seems to go towards the same direction of the Mariano's comment. I definitely prefer "add" rather than "insert". Any RTF member interested in QVTo, please have a look to the follow up discussion I created yesterday with respect to model extents. I want to come up with a consistent resolution for a new issue I'm going to send, which should deal with many parts of the specification (InstantionExp, ObjectExp, MappingParameter, and clone/deepClone). Regards, Adolfo. On 06/02/2014 06:05, Ed Willink wrote: Hi Resurrected from the OMG mail archives: ************************************ Solution suggested by Mr. Mariano Belaunde: Currently in a mapping operation or in an explicit object _expression_, if you do not indicate the extent, then by default the newly created object is automatically inserted to an inferred extent. We could imagine a different rule: in order for a created element to be inserted into an extent, make it explicit. Like in: mapping A::foo() : X@myextent { ... } x := object X@myextent { ... } We could also add a 'insertElement()' operation, in the cases where the inclusion to an extent has to be performed at a different time. ************************************ Regards Ed Willink