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.
_______________________________________________
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