Re: [qvto-dev] Issue 13103 - Element creation/attachmenty/detachment (wa

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

Sergey: Your response a year and a half ago was 'helpful' in deferring a resolution and raising a new much simpler issue: "Specify the utility of an extent".

I thought I had a solution until I reviewed the emails and found your comments.

You observed that EMF supports cross-resource containment and that perhaps MOF Extents do too for QVTo.

So the questions we have to answer are:

Can an output object be in more than one QVTo extent? (MOF extents allow it)
Would ModelElement::addElement auto removeElement from a previous extent?
Does Model::removeElement need to be so brutal about killing cross-references?
Should it be deleteElement if it is so brutal?
Why doesn't Model::removeElement remove cross-references from other extents too?
Can an output containment relationship cross QVTo extent boundaries? (MOF extents allows it)
What happens to objects not in an extent? (proposal auto-extents on exit to first out extent).
How many extents does assignment of an object's container affect?
What does it mean for an explicit object create into extent @A to get added to @B by inferred/explicit mapping output?

And; is it appropriate to emulate EMF cross-resource containment with extents?
Do we want to support generation of multi-extent outputs?
Take the case of a simple output structure, parent model, containing N child models. N is unknown so even with the collection of models extension, we cannot have N+1 output extents. It is necessary to dynamically create and execute a transformation with N+1 output and extents in order to synthesize the output. If we really want this, surely we want a one extent output that can have a dynamic number of sub-extents. It is then an implementation problem as to how the sub-extents are mapped to physical files.

[Most of these questions are at least partially applicate to QVTr/QVTc]

And another couple:

Are Model and Extent the same concept?
What is the QVT value of MOF Extent's useContainment()
How do multi-Models relate to multi-Extents?

I see three designs:

a) very simple: Model extends URIExtent
Model containment tree is just sensible
adding things to an Extent is just confusing specification bloat relevant only relevant when an object ends up as an orphan; easy fixed by a default.

• generally this is what everyone expects

b) intermediate: Model represents the logical containment tree
QVTExtent extends URIExtent and labels model sub-trees for persistence in a per-sub-tree physical resources
at most one extent per model element
adding things to an Extent is just confusing specification bloat relevant only relevant when an object ends up as an orphan; easy fixed by a default.

• more powerful, but confusing and we have to sort out all the migrations

c) complex: Model represents the logical containment tree
QVTExtent extends URIExtent and identifies model region(s) for persistence in a single model
arbitrary number of extenst per model element

• very powerful, very confusing and we have to sort out all the location / migration rules
• who wants it?

----

Fundamentally is there something good about the current @XXX and inference or is it all irrelevant?

QVTo has now had a functioning implementation for well over five years, so I see no excuse to defer yet again. We should be able to identify what is actually required. I favour trimming to the simple Model is a URIExtent solution, leaving residence to be resolved by containment, requiring only a little bit of rescue for orphans.

    Regards

        Ed Willink


On 06/02/2014 19:53, Sergey Boyko wrote:

Hi Adolfo,

I would add a few words on using of model extent in ObjectExp. 

Technically (and EMF supports that) the containment hierarchy may be split between several extents (Resources in terms of EMF). So even for non-root object it sometimes may be necessary to explicitly specify extent for the object being created.

I like the idea to add 'Model::addElement(..)' operation. I think it's a good companion for 'Model::removeElement()'.

Also I believe that implicit extent should be inferred for all cases ObjectExp/InstantiationExp/MappingOperation, not least because of the backward compatibility.

Regards,

  Sergey.

On Wed, Feb 5, 2014 at 11:14 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

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ánchez-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üngliche Nachricht-----
Von: qvto-dev-bounces@xxxxxxxxxxx
[mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Montag, 3. Februar 2014 20:02
An: qvt-rtf@xxxxxxx; 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

_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev

_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3684/7068 - Release Date: 02/06/14